Re: [EEYEB-20050523] Windows Kernel APC Data-Free Local Privilege Escalation Vulnerability
Ron <[email protected]> Tue, 13 Dec 2005 12:40:09 -0600
| Newsgroups | gmane.comp.security.full-disclosure,gmane.comp.security.bugtraq,gmane.comp.security.ntbugtraq |
|---|---|
| Message-ID | <[email protected]> |
Some versions of Nessus can log in through SSH and check the system locally. I'm unsure if Retina can do that, but it wouldn't surprise me. Joshua Russel wrote: > It is a local vulnerability, then how does Retina claims to scan it remotely? > > > On 12/13/05, Advisories <[email protected]> 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 >> [email protected] 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/ >> > _______________________________________________ > 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/