It is a local vulnerability, then how does Retina claims to scan it remotely? On 12/13/05, Advisories <Advisories@xxxxxxxx> wrote: > Windows Kernel APC Data-Free Local Privilege Escalation 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 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. > > Technical Details: > 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. > > 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 > alert@xxxxxxxx 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 > user's 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/ >
