|
Windows Kernel APC Data-FreeLocal Privilege Escalation Vulnerability |
|
|
|
|
Thursday, 15 December 2005 |
Vulnerability
>> >
>> > Release Date:
>> > December 13, 2005
>> >
>> > Date Reported:
>> > May 23, 2005
>> >
>> > External Refferences:
>> > eEye ID# EEYEB-20050523
>> > OSVDB ID# 18823
>> > CVE # CAN-2005-2827
>> > Microsoft # MS05-055
>> >
>> > Severity:
>> > Medium (Local Privilege Escalation to Kernel)
>> >
>> > Systems Affected:
>> > Windows NT 4.0
>> > Windows 2000
>> >
>> > Overview:
>> > 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
>> > codes 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.
>> >
>> > Technical Details:
>> > The basis of this vulnerability is in PspExitThreads APC
> freeing loop
>> > and in the behavior of KiMoveApcState, invoked from KiAttachProcess
>> > and KeUnstackDetachProcess. Well 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
> threads 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
> processs 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
>> > processs 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 processs 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 threads 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 threads 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.
>> >
>> > Protection:
>> > Retina Network Security Scanner has been updated to identify 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
>> >
>> > Credit:
>> > Derek Soeder
>> >
>> > Greetings:
>> > Dedicated to
>> >
>> > R. W. S., Sr.
>> > 1928 - 2005
>> >
>> > >From my father to his:
>> >
>> > "He was a good man; liked by all, loved by many. He was always
>> > upbeat, outgoing and loved to kid around. He was always willing to
>> > help others in their time of need and gave a lot of
> himself. He was
>> > very creative, handy with tools, and could fix about
> anything. He was
>> > the one everyone turned to for advice and direction. He was my
>> > father, and I miss him dearly."
>> >
>> > Copyright (c) 1998-2005 eEye Digital Security Permission is hereby
>> > granted for the redistribution of this alert electronically. It is
>> > not to be edited in any way without express consent of
> eEye. If you
>> > wish to reprint the whole or any part of this alert in any other
>> > medium excluding electronic medium, please email
This email address is being protected from spam bots, you need Javascript enabled to view it
for
>> > permission.
>> >
>> > Disclaimer
>> > The information within this paper may change without
> notice. Use of
>> > this information constitutes acceptance for use in an AS IS
> condition.
>> > There are no warranties, implied or express, with regard to this
>> > information. In no event shall the author be liable for
> any direct or
>> > indirect damages whatsoever arising out of or in connection
> with the
>> > use or spread of this information. Any use of this
> information is at
>> > the users own risk.
>> > _______________________________________________
>> > Full-Disclosure - We believe in it.
>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> > Hosted and sponsored by Secunia - http://secunia.com/
>> >
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/ |
|
|