Date: Tue, 13 Dec 2005 13:47:17 -0800
From: "Marc Maiffret" <mmaiffret@...e.com>
To: <full-disclosure@...ts.grok.org.uk>,
	<bugtraq@...urityfocus.com>
Subject: RE: [EEYEB-20050523] Windows Kernel APC
	Data-FreeLocal Privilege Escalation Vulnerability


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@...ts.grok.org.uk 
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf 
> Of Joshua Russel
> Sent: Tuesday, December 13, 2005 10:28 AM
> To: Advisories
> Cc: full-disclosure@...ts.grok.org.uk; 
> vulnwatch@...nwatch.org; bugtraq@...urityfocus.com; 
> ntbugtraq@...ugtraq.com
> 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@...e.com> 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@...e.com 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/

Powered by blists - more mailing lists