RE: [Full-disclosure] [EEYEB-20050523] Windows Kernel APC Data-FreeLocal Privilege Escalation Vulnerability

["Marc Maiffret" <mmaiffret@xxxxxxxx>]

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/
> 
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/