exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

dll_advisory.txt

dll_advisory.txt
Posted Aug 17, 1999

dll_advisory.txt

SHA-256 | 632a097ad3c0e2f6702f4d1644c30d7a2ea2b67b56a4c641289878d9dee82b28

dll_advisory.txt

Change Mirror Download

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 <paul@ARGO.DEMON.CO.UK>
To: BUGTRAQ@netspace.org
Subject: Re: L0pht Security Advisory: Windows NT

Dildog <dildog@L0PHT.COM> 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 <Russ.Cooper@RC.ON.CA>
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
<http://support.microsoft.com/support/kb/articles/q218/4/73.asp>
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 <Russ.Cooper@RC.ON.CA>
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.

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    0 Files
  • 20
    Mar 20th
    0 Files
  • 21
    Mar 21st
    0 Files
  • 22
    Mar 22nd
    0 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    0 Files
  • 26
    Mar 26th
    0 Files
  • 27
    Mar 27th
    0 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close