COMMAND
kernel
SYSTEMS AFFECTED
Windows NT/2000
PROBLEM
'Quimeras' found following. Local and remote execution of trojan
programs in other user accounts included Administrator. As SDK
says, when calling CreateProcess(), if the executable file name
does not contain a directory path, the system searches for the
executable file in the following sequence:
- The directory from which the application loaded
- The current directory for the parent process
- Windows NT/2000: The 32-bit Windows system directory. Use
the GetSystemDirectory function to get the path of this
directory. The name of this directory is System32
- Windows NT/2000: The 16-bit Windows system directory. There
is no Win32 function that obtains the path of this
directory, but it is searched. The name of this directory
is System.
- The Windows directory. Use the GetWindowsDirectory function
to get the path of this directory.
- The directories that are listed in the PATH environment
variable.
Let's think about explorer.exe, by default the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Shell
has the value Explorer.exe. When a user logons the system launch
explorer.exe. Does the system look in any directory before find
it in C:\Winnt? YES !!!
To demonstrate it copy cmd.exe to your system drive root (say C:\)
and rename it to be explorer.exe then logoff and relogon. What
happen? The system spawns a command console as the actual shell
(cmd.exe renamed like explorer.exe). (To delete the trojan
explorer run C:\Winnt\explorer.exe from the command console).
If an ordinary user has write access on the system drive root
directory (by default) it is very easy to exploit this issue,
simply write a false explorer program that first launch a trojan
program and second launch the real explorer, name it explorer.exe
and copy it to the system drive root directory. Every time a user
log on interactively, the trojan program will run with that user
rigths, nothing to say if the user is in the Administrator group.
For a demonstration xploit visit
http://www.quimeras.com
Could be this remotely exploitable? Yes, this could be remotely
exploitable by an ordinary user at least in two ways. One of
these is when the system drive root directory is accesible via a
share, allowing a malicious user to put a false explorer.exe in
it.
The second way is more complex and needs the MS Telnet server
running on the target computer (for an explanation of this case
and demonstration exploit visit URL mentioned above).
When the system starts a program that uses load-time dynamic
linking, it uses the information in the file to locate the names
of the required DLLs. The system then searches for the DLLs in
the same sequence as with executables, so some system or
applications especifics dlls could be also affected.
It is easy to find more executables that could be supplanted, for
example rundll32.exe.
SOLUTION
To workaround this vulnerability be sure that all executable file
names in the registry are preceded by the appropiate path. You
also can move a copy of real explorer.exe to the system drive root
directory and give special rights on it.
Allot of vulnerabilities/exploits will appear in the future based
on this System behaviour when looking for EXEs and DLLs.
Patch availability:
- Microsoft Windows NT 4.0 Workstation, Windows NT 4.0 Server,
and Windows NT 4.0 Server, Enterprise Edition:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23360
- Microsoft Windows NT 4.0 Server, Terminal Server Edition
patches will be available soon.
- Microsoft Windows 2000 Professional, Server, and Advanced
Server:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23359