[41635] in bugtraq
RE: [Full-disclosure] [EEYEB-20050523] Windows Kernel APC Data-FreeLocal Privilege Escalation Vulnerability
daemon@ATHENA.MIT.EDU (Marc Maiffret)
Wed Dec 14 13:30:01 2005
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Date: Tue, 13 Dec 2005 13:47:17 -0800
Message-ID: <A641CEADDBAEAE4C96FC5BF854695268A93A19@av-mail01.corp.int-eeye.com>
From: "Marc Maiffret" <mmaiffret@eeye.com>
To: <full-disclosure@lists.grok.org.uk>, <bugtraq@securityfocus.com>
Content-Transfer-Encoding: 8bit
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
> [mailto:full-disclosure-bounces@lists.grok.org.uk] On Behalf
> Of Joshua Russel
> Sent: Tuesday, December 13, 2005 10:28 AM
> To: Advisories
> Cc: full-disclosure@lists.grok.org.uk;
> vulnwatch@vulnwatch.org; bugtraq@securityfocus.com;
> ntbugtraq@ntbugtraq.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@eeye.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@eEye.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/
>
