Date: Tue, 13 Dec 2005 12:40:09 -0600
From: Ron <iago@...hallalegends.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	ntbugtraq@...ugtraq.com
Subject: Re: [EEYEB-20050523] Windows Kernel APC Data-Free
	Local Privilege Escalation Vulnerability


Some versions of Nessus can log in through SSH and check the system 
locally.  I'm unsure if Retina can do that, but it wouldn't surprise me.

Joshua Russel wrote:
> 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