[17322] in bugtraq
Registry Permissions reminder - local privilege escalation on
daemon@ATHENA.MIT.EDU (David Litchfield)
Tue Oct 24 02:29:25 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <000901c03d59$53991960$e7e593c3@david>
Date: Mon, 23 Oct 2000 21:25:41 -0400
Reply-To: David Litchfield <mnemonix@GLOBALNET.CO.UK>
From: David Litchfield <mnemonix@GLOBALNET.CO.UK>
X-To: ntbugtraq@listserv.ntbugtraq.com
To: BUGTRAQ@SECURITYFOCUS.COM
Howdy all,
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}\InProcSer
ver32
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;
}
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 - for anyone interested I'll be speaking
about this as part of my talk at Blackhat (http://www.blackhat.com) in
Amsterdam on Wednesday.
Cheers,
David Litchfield
@stake http://www.atstake.com
