The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Windows Kernel APC Data-Free Local Privilege Escalation (MS05-055)
------------------------------------------------------------------------
SUMMARY
eEye Digital Security has discovered a local privilege escalation
vulnerability in the Windows kernel that could allow any code executing on
a Windows NT 4.0 or Windows 2000 system to elevate itself to the highest
possible local privilege level (kernel). For example, a malicious user,
network worm, or e-mail virus could take advantage of this vulnerability
in order to completely compromise the vulnerable system on which the
exploit code is executing, regardless of that code's original privilege
level.
The vulnerability exists in the thread termination routine contained
within NTOSKRNL.EXE. Through a specific series of steps, a local attacker
can cause the code responsible for discarding queued Asynchronous
Procedure Call (APC) entries to erroneously attempt to free a region of
kernel data, producing a "data free" vulnerability that may be exploited
in order to alter arbitrary kernel memory, or even divert the flow of
execution directly.
DETAILS
Vulnerable Systems:
* Windows NT 4.0
* Windows 2000
The basis of this vulnerability is in PspExitThread's APC freeing loop and
in the behavior of KiMoveApcState, invoked from KiAttachProcess and
KeUnstackDetachProcess. We'll give a description of the problem below,
followed by a "call flow" illustration to outline the specific sequence of
events.
When a thread is exiting, PspExitThread will detach the thread's APC
queues from ETHREAD.ApcState.ApcListHead[0] and ApcListHead[1], so that
each queue is now a circular, doubly-linked list in which the first and
last nodes do not point back to the list head (LIST_ENTRY structure).
However, since the list heads' pointers are not modified, the purpose is
presumably just to allow the APC freeing loop within PspExitThread to walk
each list and free its nodes, without navigating back to the list head and
erroneously attempting to free memory within the ETHREAD structure. Of
course, the vulnerability is that this can be made to happen, and the
result is a "data free" condition that eventually causes ExFreePoolWithTag
to operate on user memory.
APCs queued by an external process count against that process's pool
quota, and therefore the quota block of the pool block containing the APC
structure has a reference to the queuing process. If the exiting thread
contains an APC queued by a now-terminated external process in its lists,
and if that APC node represents the last reference to the process's
Process object, then freeing that node will cause the Process object to be
destroyed from within ExFreePoolWithTag. Part of this sequence involves
executing PspProcessDelete, which switches to the ending process's address
space using KeStackAttachProcess, calls PspExitProcess, and then reverses
the switch with KeUnstackDetachProcess.
Both the "attach" and "detach" functions call KiMoveApcState, which is
intended to temporarily strip the thread of its APCs so that none are
dispatched in an address space for which they were not intended, then
re-link the list of APCs after the thread's native address space is
reinstated. During attach, the ETHREAD.ApcState structure is duplicated,
and the pointers of the lists' first and last nodes are adjusted to refer
to the copy. Upon detach, the first and last nodes' pointers are adjusted
to re-link the lists to the original ETHREAD.ApcState -- even though they
were supposed to remain disconnected, since the APC free loop is still in
progress. The end result is that the free loop will continue and attempt
to free a portion of the ETHREAD structure as though it were a pool block
header, culminating in the kernel operating on attacker-supplied pointers
from user-land memory, because the accessed portion of ETHREAD contains
predictable and mostly zeroed values.
The following depicts the sequence of function calls and parameters
involved in producing the vulnerable condition:
PspExitThread
. KeFlushQueueApc
. (detaches APC queues from ETHREAD.ApcState.ApcListHead)
. (APC free loop begins)
. ExFreePool(1st_APC -- queued by exited_process)
. . ExFreePoolWithTag(1st_APC)
. . . ObfDereferenceObject(exited_process)
. . . . ObpRemoveObjectRoutine
. . . . . PspProcessDelete
. . . . . . KeStackAttachProcess(exited_process)
. . . . . . . KiAttachProcess
. . . . . . . . KiMoveApcState(ETHREAD.ApcState --> duplicate)
. . . . . . . . KiSwapProcess
. . . . . . PspExitProcess(0)
. . . . . . KeUnstackDetachProcess
. . . . . . . KiMoveApcState(duplicate --> ETHREAD.ApcState)
. . . . . . . KiSwapProcess
. ExFreePool(2nd_APC)
. ExFreePool(ETHREAD + 30h)
. (APC free loop ends)
The ETHREAD data upon which ExFreePool is called is mostly predictable,
KernelStack at offset +28h being the single true variable; however,
methods for leaking a thread's kernel ESP permit complete control over the
path execution will take through ExFreePoolWithTag. With enough crafting,
an arbitrary function pointer can be supplied as an object type method,
allowing execution to be hijacked directly.
Beginning with Windows XP, KeFlushQueueApc contains a code fix that
resolves this vulnerability.
Vendor Status:
Microsoft has released a patch for this vulnerability. The patch is
available at:
<http://www.microsoft.com/technet/security/bulletin/MS05-055.mspx>
http://www.microsoft.com/technet/security/bulletin/MS05-055.mspx
ADDITIONAL INFORMATION
The original article can be found at:
<http://www.eeye.com/html/research/advisories/AD20051213.html>
http://www.eeye.com/html/research/advisories/AD20051213.html
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
