L0pht Security Advisory Release date: February 18, 1999 Application: Microsoft Windows NT 4.0 Severity: any local user can gain administator privileges and/or take full control over the system Author: dildog@l0pht.com URL: http://www.L0pht.com/advisories.html --- Overview : --- Microsoft Windows NT 4.0 implements a system-wide cache of file-mapping objects for the purpose of loading system dynamic link libraries (DLLs) as quickly as possible. These cache objects, located in the system's internal object namespace, are created with permissions such that the 'Everyone' group has full control over them. Hence, it is possible to delete these cache objects and replace them with others that point to different DLLs. When processes are created, the loader maps/loads the loading executable's imported DLLs into the process space. If there is a DLL cache object available, it is simply mapped into the process space, rather than going to the disk. Hence, there is an exploitable condition, when a low-privilege user replaces a DLL in the cache with a trojan DLL, followed by a high-privelege account launching a process. The high priveleged process will map in the trojan DLL and execute code on behalf of the low privelege use r. --- Affected systems: --- Windows NT 4.0 Server SP4 Windows NT 4.0 Workstation SP4 Other service packs are likely to be vulnerable, but the exploit has not been tested on them, neither has the fix presented below. --- Description : --- The Windows NT object namespace is the place where the kernel keeps the names of mutexes, semaphores, filemapping objects, and other kernel objects. It is organized hierarchically, like a directory structure. Amongst the directories are: \Device \BaseNamedObjects \Driver \KnownDlls ... The NT object namespace is browsable with a tool called 'WinObj 2.0' from System Internals (their website is http://www.sysinternals.com). You may wish to look around this namespace and browse the default permissions of objects. It is quiet entertaining, really. The "\Knowndlls" directory contains a list of DLLs in the c:\winnt\system32 directory, like: \KnownDlls\COMCTL32.dll \KnownDlls\MPR.dll \KnownDlls\advapi32.dll \KnownDlls\kernel32.dll .. All of these objects are created at boot time, and are 'permanent shared objects'. Normally, users can not create permanent shared objects (it's an advanced user right, and it is normally not assigned to any group, even Administrators). But the system pr eloads this cache for you. Permanent shared objects differ from regular shared objects only in the fact that they have a flag set, and an incremented reference count, such that if you create one, and then terminate the creating process or close all handle s to the object, it does not disappear from the object space. To exploit the poor permissions on this cache, one first needs to delete one of the shared objects by name, in order to later replace it. So we make a call to the NTDLL.DLL native function "OpenSection()", getting a handle to the object. Then we call the NTOSKRNL.EXE native function "ZwMakeTemporaryObject()" which removes the 'permanent' flag and decrements the reference counter from the object. Now we just call NTDLL.DLL:NtClose() on the handle and it is destroyed. To create a section, one calls NTDLL.DLL:CreateSection(), which is undocumented. There are other calls one needs to make in order to set up the object and open the KnownDlls directory, but they are trivial and will not be discussed here. Feel free to bro wse the source code presented at the end of this advisory to see what you need to do though. Anyway, you create a section (aka file-mapping) object that points to a trojan DLL. A good candidate for DLL trojan is KERNEL32.DLL, since it is loaded by pretty much every executable you're going to run. Note that any DLL cache objects you create as a user can not be 'permanent', hence, when you log out, the cache object _will_ disappear. So how can we get a higher privelege process to run while we're logged in? There are many ways. We can wait for an 'A t' job to go off, or we can set up the DLL hack as an 'At' job that goes off when someone else is logged in. But more reliable is this: When a new Windows NT subsystem is started, it creates a subsystem process to handle various system details. Examples of these processes are LSASS.EXE and PSXSS.EXE. The PSXSS.EXE is the POSIX subsystem. But since no one ever really uses the POSIX subsys tem under NT. So, chances are, it won't be loaded into memory yet. Once it is, though, it's loaded until the machine reboots. If it loaded, reboot the machine, and it won't be :P. So, we launch our DLL cache hack, and then run a POSIX subsystem command, thus launching PSXSS.EXE (which runs as 'NT AUTHORITY\SYSTEM', the system account), and running our DLL with local administrator privileges. Incidentally, other subsystems have the same effect, such as the OS/2 subsystem (the only other one that probably isn't started yet). --- Workarounds/Fixes: --- I developed a patch for this security problem in the form of a Win32 Service program that can be installed by the Administrator of the system. It sets itself to run every time the system is started, and before the user has the opportunity to start a program, it adjusts the permissions of the DLL cache to something much safer. The source code for t his service is also provided, along with a compiled version. Links to the programs can be found at http://www.l0pht.com/advisories.html. One can verify the validity of the patch by downloading the WinObj v2.0 tool from System Internals (www.sysinternals.com) and inspecting the permissions of the KnownDlls directory, and the section objects within it. Microsoft has been sent a copy of this advisory, and I would expect a hotfix from them at some point in the near future. --- Example : --- I wrote up a trojan to test exploitability, and it was a simple 'forwarder' DLL that had the same exported names as KERNEL32.DLL, but a different 'DllMain()' function, to be called when the DLL is loaded. The function calls in my trojan, simply forward o ff to the real KERNEL32.DLL calls located in a copy of the kernel that you make in 'REALKERN.DLL' in the c:\temp directory. To try out this vulnerability, obtain an account as a low-privilege guest user (referred to as 'Dick') and do the following: 1. Log in as Dick at the console. 2. Start up two "cmd.exe" shells. Do the following in one of them. 3. Copy c:\winnt\system32\kernel32.dll to c:\temp\realkern.dll (The egg dll is hard coded to use the c:\temp directory to find this file. If you can't put it in c:\temp, then modify the source '.def' file to point to a different location and recompile eggdll.dll) 4. Copy the provided hackdll.exe and eggdll.dll to c:\temp 5. Ensure that there is no file named c:\lockout. If there is, delete it. The exploit uses this file as a lockfile. 5. Delete the KERNEL32.DLL file-mapping object from the system cache: c:\> cd\temp c:\temp> hackdll -d kernel32.dll 6. Insert the new file-mapping object with: c:\temp> hackdll -a kernel32.dll c:\temp\eggdll.dll Don't hit a key in this window after hitting enter. 7. Now move to the other cmd.exe window that you started. 8. Run a POSIX subsystem command. A good way to start it is: c:\temp> posix /c calc (if you have calculator installed. If not, pick some other program) 9. Now the EGGDLL.DLL will prompt you with a few message boxes: Say no to the "User is DOMAIN\DICK, Spawn Shell?" box. Say no to the "User is \[garbage], Spawn Shell?" box. Say YES to the "User is NT AUTHORITY\SYSTEM, Spawn Shell?" box. Say YES to the "Winsta0" window station message box. Say YES to the "Desktop" window desktop message box. You will now see a "System Console" command.com shell open up. (saying yes to the next 'winlogon' box will give you something funny when you log out, btw :P) 10. Now go back to your first cmd.exe window and hit a key to unpoison the DLL cache. 11. In the System Console window, run the User Manager program, and modify Dick's account (or anyone else's for that matter) to your hearts content. (NT Server) c:\winnt\system32> usrmgr (NT Workstation) c:\winnt\system32> musrmgr --- Source and Compiled Code: --- Exploit code can be downloaded from L0pht's website at http://www.l0pht.com/advisories.html. It is available in compiled form, and in pure source form as two zipfiles. The L0pht patch for this advisory is also available in both source form and compiled f orm from the same URL. dildog@l0pht.com --------------- For more L0pht (that's L - zero - P - H - T) advisories check out: http://www.l0pht.com/advisories.html --------------- ---------------------------------------------------------------------------- Date: Fri, 19 Feb 1999 11:23:44 +0000 From: Paul Ashton To: BUGTRAQ@netspace.org Subject: Re: L0pht Security Advisory: Windows NT Dildog writes: > L0pht Security Advisory > --- > Workarounds/Fixes: > --- > > I developed a patch for this security problem in the form of a > Win32 Service program that can be installed by the Administrator of the > system. It sets itself to run every time the system is started, and before > the user has the opportunity to start a program, it adjusts the > permissions of the DLL cache to something much safer. Alternatively, you can set HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\ProtectionMode=1 and reboot. Paul ---------------------------------------------------------------------------- Date: Mon, 22 Feb 1999 12:12:01 -0500 From: Russ To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Alert: Microsoft Security Bulletin (MS99-006) - KnownDLLs List Vu lnerability Microsoft have released a Security Bulletin (http://www.microsoft.com/security/bulletins/ms99-006.asp) which covers an issue raised by Dildog and the l0pht in their February 18, 1999 L0pht Security Advisory (http://www.l0pht.com/advisories.html). Dildog went to great lengths, and considerable effort, to demonstrate how it might be possible to poison the DLL cache on an NT system, a feat which might result in being able to Trojan a system DLL resulting in a system compromise. Microsoft's bulletin points out that there has been (at least since May 8th, 1998, possibly earlier) a mechanism to prevent Dildog's exploit. It is covered in the NT 4.0 Resource Kit, as well as Microsoft's White Paper on "Securing Windows NT Installation" (http://www.microsoft.com/ntserver/security/exec/overview/Secure_NTInsta ll.asp). They acknowledge, however, that the Out of the Box installation should set the permissions differently than they are now, and have said they are working on a Hot Fix which will change those permissions. I contacted Dildog and asked him whether or not he was aware of the mechanism, a value known as "ProtectionMode" under the HKLM\System\CCS\Control\SessionManager key. He wasn't. More importantly, I asked whether or not his testing was being done on an NT System which followed Microsoft's guidelines for secure installation. It wasn't. I found that quite interesting. Its worth pointing out here that some MS documentation refer to this value being present under the "Session Manager" key rather than the "SessionManager" key (note that one has a space between the words). More references are currently available for it under "SessionManager" than not, including the above-mentioned White Paper and the current Security Bulletin. Microsoft have prepared a KB article describing the vulnerability. This article was not available when I checked. Cheers, Russ - NTBugtraq moderator ---------------------------------------------------------------------------- Date: Fri, 5 Mar 1999 17:14:27 -0500 From: Russ To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Alert: UPdate - Microsoft Security Bulletin (MS99-006) Microsoft have just released a patch to correct the default permissions installed in NT for the "KnownDlls" cache. The issue was first announced by Dildog in a L0pht Security Advisory (see http://www.l0pht.com/advisories.html). Microsoft's updated KB article about the issue can be seen at; http://support.microsoft.com/support/kb/articles/q218/4/73.asp which was there when I looked at it just a few moments ago. The fix, called SMSS-FIX, is now available on Microsoft's FTP site for NT and NT Terminal Server 4.0 (intel and alpha). Cheers, Russ - NTBugtraq moderator ---------------------------------------------------------------------------- Date: Fri, 5 Mar 1999 14:59:26 -0800 From: aleph1@UNDERGROUND.ORG To: BUGTRAQ@netspace.org Subject: Update to Microsoft Security Bulletin (MS99-006) The following is a Security Bulletin from the Microsoft Product Security Notification Service. Please do not reply to this message, as it was sent from an unattended mailbox. ******************************** Update to Microsoft Security Bulletin (MS99-006) ------------------------------------------------ Fix Available for Windows NT "KnownDLLs List" Vulnerability Originally Posted: February 19, 1999 Updated: March 5, 1999 Summary ======= This is an update to Microsoft Security MS99-006, which was originally issued on February 19, 1999. Microsoft is issuing this updated bulletin to inform customers of the availability of a patch, and to update the list of affected products. Microsoft has learned of a vulnerability affecting all versions of Microsoft(r) Windows NT(r) operating system, which could allow a user to gain administrative privileges on a computer. In most common usage scenarios, this vulnerability presents itself on workstations, terminal servers, and other systems that allow non-administrative users to interactively log on. Less-common configurations could also be affected, and are discussed below. The privilege elevation can be prevented by applying a hot fix that changes the default access control settings on the relevant operating system object. The hot fix is available for downloading from the Microsoft FTP site. Microsoft recommends that customers who previously made a registry change as a temporary workaround revert to the original registry setting and use the hot fix instead. Issue ===== In Windows NT, core operating system DLLs are kept in virtual memory and shared between the programs running on the system. This is done to avoid having redundant copies of the DLLs in memory, and improves memory usage and system performance. When a program calls a function provided by one of these DLLs, the operating system references a data structure called the KnownDLLs list to determine the location of the DLL in virtual memory. The Windows NT security architecture protects in-memory DLLs against modification, but by default it allows all users to read from and write to the KnownDLLs list. This is the root problem underlying the vulnerability. A user can programmatically load into memory a malicious DLL that has the same name as a system DLL, then change the entry in the KnownDLLs list to point to the malicious copy. From that point forward, programs that request the system DLL will instead be directed to the malicious copy. When called by a program with sufficiently high privileges, it could take any desired action, such as adding the malicious user to the Administrators group. It is important to understand that the user must able to run exploitation code on a machine in order to elevate their privileges. There are two types of machines at risk: - Machines that allow non-administrative users to interactively log on. Workstation and terminal servers typically do allow this, but, per standard security practices, most other servers only allow administrators to interactively log on. (Even on workstations, it's worth noting that most workstation users already are administrators on the local machine). - Machines that allow remote users to submit arbitrary programs for execution. Servers such as domain controllers, line of business servers, application servers, print and file servers and the like typically do not accept arbitrary programs for execution. It also is important to note that the scope of the privilege elevation is highly dependent on the specific machine on which the exploitation code is run. For example, a user who exploited this vulnerability on a workstation could join the local Administrators group, but could not directly exploit this vulnerability to become a domain administrator. However, a user who exploited this vulnerability on a domain controller would be able to become a domain Administrator, because the domain SAM is shared among all domain controllers. While there are no reports of customers being adversely affected by this privilege elevation vulnerability, Microsoft is proactively providing information to allow customers to prevent it. The hot fix changes the default permissions on the KnownDLLs list to read-only, and is the recommended corrective action for this vulnerability. The initial version of this bulletin provided a workaround in the form of a registry change that restricts users' ability to change system base objects, including the KnownDLLs list. Although the registry change corrects the problem, it encompasses a broader range of system behavior than the hot fix, and may not be appropriate for all systems. Affected Software Versions ========================== - Microsoft Windows NT Workstation 4.0 - Microsoft Windows NT Server 4.0 - Microsoft Windows NT Server 4.0, Enterprise Edition - Microsoft Windows NT Server 4.0, Terminal Server Edition What Microsoft is Doing ======================= Microsoft has provided a patch that changes the default permissions on the KnownDLLs list. Information on the patch is provided below in What Customers Should Do. Microsoft also has sent this security bulletin to customers subscribing to the Microsoft Product Security Notification Service. See http://www.microsoft.com/security/services/bulletin.asp for more information about this free customer service. Microsoft has published the following Knowledge Base (KB) article on this issue: - Microsoft Knowledge Base (KB) article Q218473, Restricting Changes to Base System Objects, http://support.microsoft.com/support/kb/articles/q218/4/73.asp. (Note: It might take 24 hours from the original posting of this bulletin for the KB article to be visible in the Web-based Knowledge Base.) What customers should do ======================== Microsoft highly recommends that customers evaluate the degree of risk that this vulnerability poses to their systems and determine whether to download and install the hot fix. The hot fix changes the default permissions on the KnownDLLs list, and is the recommended means of eliminating the vulnerability. The hot fix can be found at: - X86-based Windows NT Workstation and Server 4.0 (including Enterprise Edition): ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/ usa/NT40/hotfixes-postSP4/Smss-fix/Smssfixi.exe - X86-based Windows NT Server 4.0, Terminal Server Edition: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/ usa/NT40TSE/hotfixes-postSP3/Smss-fix/Smssfixi.exe - Alpha-based Windows NT Workstation and Server 4.0 (including Enterprise Edition and Terminal Server Edition): ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/ usa/NT40/hotfixes-postSP4/Smss-fix/Smssfixa.exe - Alpha-based Windows NT Server 4.0, Terminal Server Edition: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/ usa/NT40TSE/hotfixes-postSP3/Smss-fix/Smssfixa.exe (Note: the above URLs have been word-wrapped for readability) Registry Change =============== It is also possible to eliminate this vulnerability via a registry change that enables stronger protection on system base objects such as the KnownDLLs list. However, because this registry change affects all system base objects, rather than just the KnownDLLs list, it may not be appropriate for all systems. The recommended fix for this vulnerability is via the hot fix detailed above in What Customers Should Do. Customers who previously used this registry change as a temporary workaround may wish to revert to their original setting and install the hot fix as a permanent solution. Registry Change: - Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\Session Manager (note: the key name has been word-wrapped for readability) - Name: ProtectionMode - Type: REG_DWORD - Value: 1 NOTE: Incorrectly changing the system registry can damage your system or render it inoperable, and users undertake these changes at their own risk. If you require assistance in making this change, see Obtaining Support on this Issue below. More Information ================ Please see the following references for more information related to this issue. - Microsoft Security Bulletin MS99-006, Fix Available for Windows NT "KnownDLLs List" Vulnerability (the Web-posted version of this bulletin), http://www.microsoft.com/security/bulletins/ms99-006.asp. - Microsoft Knowledge Base (KB) article Q218473, Restricting Changes to Base System Objects, http://support.microsoft.com/support/kb/articles/q218/4/73.asp. - Microsoft White Paper, Securing Windows NT Installation, available at http://www.microsoft.com/security/resources/whitepapers.asp and http://www.microsoft.com/ntserver/security/exec/ overview/Secure_NTInstall.asp Obtaining Support on this Issue =============================== If you require technical assistance with this issue, please contact Microsoft Technical Support. For information on contacting Microsoft Technical Support, please see http://support.microsoft.com/support/contact/default.asp. Acknowledgments =============== Microsoft acknowledges L0pht Heavy Industries (http://www.l0pht.com) for discovering this vulnerability. Revisions ========= - February 19, 1999: Bulletin Created - March 5, 1999: Bulletin Updated For additional security-related information about Microsoft products, please visit http://www.microsoft.com/security ------------------------------------------------------------------ THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. (c) 1999 Microsoft Corporation. All rights reserved. Terms of Use. ******************************************************************* You have received this e-mail bulletin as a result of your registration to the Microsoft Product Security Notification Service. You may unsubscribe from this e-mail notification service at any time by sending an e-mail to MICROSOFT_SECURITY-SIGNOFF-REQUEST@ANNOUNCE.MICROSOFT.COM The subject line and message body are not used in processing the request, and can be anything you like. For more information on the Microsoft Security Notification Service please visit http://www.microsoft.com/security/bulletin.htm. For security-related information about Microsoft products, please visit the Microsoft Security Advisor web site at http://www.microsoft.com/security.