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@lists.grok.org.uk=20
> [mailto:full-disclosure-bounces@lists.grok.org.uk] On Behalf=20
> Of Joshua Russel
> Sent: Tuesday, December 13, 2005 10:28 AM
> To: Advisories
> Cc: full-disclosure@lists.grok.org.uk;=20
> vulnwatch@vulnwatch.org; bugtraq@securityfocus.com;=20
> ntbugtraq@ntbugtraq.com
> Subject: Re: [Full-disclosure] [EEYEB-20050523] Windows=20
> Kernel APC Data-FreeLocal Privilege Escalation Vulnerability
>=20
> It is a local vulnerability, then how does Retina claims to=20
> scan it remotely?
>=20
>=20
> On 12/13/05, Advisories <Advisories@eeye.com> wrote:
> > Windows Kernel APC Data-Free Local Privilege Escalation=20

> 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=20
> > vulnerability in the Windows kernel that could allow any code=20
> > executing on a Windows NT 4.0 or Windows 2000 system to=20

> elevate itself=20
> > to the highest possible local privilege level (kernel). =20

> For example,=20
> > a malicious user, network worm, or e-mail virus could take=20

> advantage=20
> > of this vulnerability in order to completely compromise the=20

> vulnerable=20
> > system on which the exploit code is executing, regardless of that=20
> > code's original privilege level.
> >
> > The vulnerability exists in the thread termination routine=20

> contained=20
> > within NTOSKRNL.EXE. Through a specific series of steps, a local=20
> > attacker can cause the code responsible for discarding queued=20
> > Asynchronous Procedure Call (APC) entries to erroneously attempt to=20
> > free a region of kernel data, producing a "data free" vulnerability=20
> > that may be exploited in order to alter arbitrary kernel memory, or=20
> > even divert the flow of execution directly.
> >
> > Technical Details:
> > The basis of this vulnerability is in PspExitThread's APC=20

> freeing loop=20
> > and in the behavior of KiMoveApcState, invoked from KiAttachProcess=20
> > and KeUnstackDetachProcess. We'll give a description of=20

> the problem=20
> > below, followed by a "call flow" illustration to outline=20

> the specific=20
> > sequence of events.
> >
> > When a thread is exiting, PspExitThread will detach the=20

> thread's APC=20
> > queues from ETHREAD.ApcState.ApcListHead[0] and ApcListHead[1], so=20
> > that each queue is now a circular, doubly-linked list in which the=20
> > first and last nodes do not point back to the list head=20

> (LIST_ENTRY structure).
> > However, since the list heads' pointers are not modified,=20

> the purpose=20
> > is presumably just to allow the APC freeing loop within=20

> PspExitThread=20
> > to walk each list and free its nodes, without navigating=20

> back to the=20
> > list head and erroneously attempting to free memory within=20

> the ETHREAD=20
> > structure. Of course, the vulnerability is that this can=20

> be made to=20
> > happen, and the result is a "data free" condition that eventually=20
> > causes ExFreePoolWithTag to operate on user memory.
> >
> > APCs queued by an external process count against that=20

> process's pool=20
> > quota, and therefore the quota block of the pool block=20

> containing the=20
> > APC structure has a reference to the queuing process. If=20

> the exiting=20
> > thread contains an APC queued by a now-terminated external=20

> process in=20
> > its lists, and if that APC node represents the last=20

> reference to the=20
> > process's Process object, then freeing that node will cause the=20
> > Process object to be destroyed from within=20

> ExFreePoolWithTag. Part of=20
> > this sequence involves executing PspProcessDelete, which=20

> switches to=20
> > the ending process's address space using=20

> KeStackAttachProcess, calls=20
> > PspExitProcess, and then reverses the switch with=20
> > KeUnstackDetachProcess.
> >
> > Both the "attach" and "detach" functions call=20

> KiMoveApcState, which is=20
> > intended to temporarily strip the thread of its APCs so=20

> that none are=20
> > dispatched in an address space for which they were not=20

> intended, then=20
> > re-link the list of APCs after the thread's native address space is=20
> > reinstated. During attach, the ETHREAD.ApcState structure is=20
> > duplicated, and the pointers of the lists' first and last nodes are=20
> > adjusted to refer to the copy. Upon detach, the first and=20

> last nodes'
> > pointers are adjusted to re-link the lists to the original=20
> > ETHREAD.ApcState -- even though they were supposed to remain=20
> > disconnected, since the APC free loop is still in progress.=20

> The end=20
> > result is that the free loop will continue and attempt to free a=20
> > portion of the ETHREAD structure as though it were a pool block=20
> > header, culminating in the kernel operating on attacker-supplied=20
> > pointers from user-land memory, because the accessed portion of=20
> > ETHREAD contains predictable and mostly zeroed values.
> >
> > The following depicts the sequence of function calls and parameters=20
> > involved in producing the vulnerable condition:
> >
> > . PspExitThread
> > . . KeFlushQueueApc
> > . . (detaches APC queues from ETHREAD.ApcState.ApcListHead)=20

> . . (APC=20
> > free loop begins) . . ExFreePool(1st_APC -- queued by=20

> exited_process)=20
> > . . . ExFreePoolWithTag(1st_APC) . . . .=20
> > ObfDereferenceObject(exited_process)
> > . . . . . ObpRemoveObjectRoutine
> > . . . . . . PspProcessDelete
> > . . . . . . . KeStackAttachProcess(exited_process)
> > . . . . . . . . KiAttachProcess
> > . . . . . . . . . KiMoveApcState(ETHREAD.ApcState -->=20

> duplicate) . . .=20
> > . . . . . . KiSwapProcess . . . . . . . PspExitProcess(0) .=20

> . . . . .=20
> > . KeUnstackDetachProcess . . . . . . . .=20

> KiMoveApcState(duplicate -->=20
> > ETHREAD.ApcState) . . . . . . . . KiSwapProcess . .=20
> > ExFreePool(2nd_APC) . . ExFreePool(ETHREAD + 30h) . . (APC=20

> free loop=20
> > ends)
> >
> > The ETHREAD data upon which ExFreePool is called is mostly=20
> > predictable, KernelStack at offset +28h being the single true=20
> > variable; however, methods for leaking a thread's kernel ESP permit=20
> > complete control over the path execution will take through=20
> > ExFreePoolWithTag. With enough crafting, an arbitrary function=20
> > pointer can be supplied as an object type method, allowing=20

> execution to be hijacked directly.
> >
> > Beginning with Windows XP, KeFlushQueueApc contains a code fix that=20
> > resolves this vulnerability.
> >
> > Protection:
> > Retina Network Security Scanner has been updated to identify this=20
> > vulnerability.
> >
> > Vendor Status:
> > Microsoft has released a patch for this vulnerability. The=20

> patch is=20
> > available at:
> > http://www.microsoft.com/technet/sec.../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=20
> > upbeat, outgoing and loved to kid around. He was always willing to=20
> > help others in their time of need and gave a lot of=20

> himself. He was=20
> > very creative, handy with tools, and could fix about=20

> anything. He was=20
> > the one everyone turned to for advice and direction. He was my=20
> > father, and I miss him dearly."
> >
> > Copyright (c) 1998-2005 eEye Digital Security Permission is hereby=20
> > granted for the redistribution of this alert electronically. It is=20
> > not to be edited in any way without express consent of=20

> eEye. If you=20
> > wish to reprint the whole or any part of this alert in any other=20
> > medium excluding electronic medium, please email alert@eEye.com for=20
> > permission.
> >
> > Disclaimer
> > The information within this paper may change without=20

> notice. Use of=20
> > this information constitutes acceptance for use in an AS IS=20

> condition.
> > There are no warranties, implied or express, with regard to this=20
> > information. In no event shall the author be liable for=20

> any direct or=20
> > indirect damages whatsoever arising out of or in connection=20

> with the=20
> > use or spread of this information. Any use of this=20

> information is at=20
> > 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/
>=20