COMMAND
registry permissions
SYSTEMS AFFECTED
Windows NT
PROBLEM
David Litchfield found following. The generic security issue of
lax permissions on registry keys under Windows NT 4 has been
known for sometime (see Stephen Sutton's Windows NT Security
Guidelines http://www.trustedsystems.com/tss_nsa_guide.htm ) but
here's a "new" curtly reminder of why it is so important to do so.
Local privilege escalation can be achieved on Windows NT 4, due
to weak permissions on a registry key that controls the Microsoft
Installer Service. When a user double clicks on a valid .msi
file the Microsoft Installer Service (MSIEXEC) is started. As
part of the MSIEXEC startup process it reads in the name of the
DLL set in the following registry key:
HKLM\Software\Classes\CLSID\{000C103E-0000-0000-C000-000000000046}\InProcServer32
by default, normally C:\winnt\system32\msi.dll.
Once this DLL has been loaded into the address space of MSIEXEC,
the DllGetClassObject() function exported by msi.dll is called.
Due to the permissions on this registry key any user that may log
on to the system locally, can modify the value - as the
Interactive user. By creating their own DLL that exports a
function called DllGetClassObject() and pointing this key to their
own DLL, rather than msi.dll they can gain complete control over
the system. For example the following code, compiled into a DLL
will give an Interactive command shell with SYSTEM privileges
when the user then double clicks on an MSI file.
#include <stdio.h>
__declspec(dllexport)int DllGetClassObject()
{
system("cmd.exe");
return 0;
}
SOLUTION
To resolve this issue, and any others like it, ensure that only
Administrators may set regsitry key values under
HKLM\Software\Clsid - Interactive only needs the read permission.
On web servers that allow publishing it is crucial to ensure that
these issues don't exist as this attack can be lauched using ASP.