Executable Path Searching Vulnerability in Windows NT/2000 (fwd)

[Alfred Huger <ah () SECURITYFOCUS COM>]

---------- Forwarded message ----------
Date: Wed, 26 Jul 2000 18:32:51 +0200
From: Quimeras <quimeras () quimeras com>
To: Quimeras <quimeras () quimeras com>
Subject: Executable Path Searching Vulnerability in Windows NT/2000

Hello all,

Kerberos, Active Directory, NTFS 5, COM+, ...
But simple things still work and the door is open for anyone who looks for
it!

Microsoft was informed about this 3 weeks ago.

EXECUTABLE PATH SEARCHING VULNERABILITY IN WINDOWS NT/2000
----------------------------------------------------------------------------
--------
Date: July 2000

Risks: Local and remote execution of trojan programs in other user accounts
included Administrator.

Systems affected:
    Windows 2000 Professional vulnerable
    Windows 2000 Server vulnerable
    Windows NT 4.0 vulnerable

The basis
-----------
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.

An implication
----------------
Let's think about explorer.exe, by default the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\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).

The trivial exploit
--------------------
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 xploit
visit http://www.quimeras.com).

What else ?
--------------
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.

Workaround
---------------
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.

Future
-------
I think a lot of vulnerabilities/exploits will appear in the future based on
this System behaviour when looking for EXEs and DLLs.

? 2000 The Quimeras Company. Alberto Aragones.
All rights reserved. Unauthorized duplication expressly prohibited.
Link to http://www.quimeras.com