To be clear we did not make any claim except that Retina has been updated to be able to identify this vulnerability. Obviously being that it is a local vulnerability we audit for the vulnerability using credentials through normal means that you should find in most any vulnerability assessment scanner. -Marc > -----Original Message----- > From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx > [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf > Of Joshua Russel > Sent: Tuesday, December 13, 2005 10:28 AM > To: Advisories > Cc: full-disclosure@xxxxxxxxxxxxxxxxx; > vulnwatch@xxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx; > ntbugtraq@xxxxxxxxxxxxx > Subject: Re: [Full-disclosure] [EEYEB-20050523] Windows > Kernel APC Data-FreeLocal Privilege Escalation Vulnerability > > 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/ > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ >
