[41688] in bugtraq
Re: [Full-disclosure] [EEYEB-20050523] Windows Kernel APC Data-Free
daemon@ATHENA.MIT.EDU (Ron)
Fri Dec 16 00:41:31 2005
Message-ID: <439F1589.8070800@valhallalegends.com>
Date: Tue, 13 Dec 2005 12:40:09 -0600
From: Ron <iago@valhallalegends.com>
MIME-Version: 1.0
Cc: full-disclosure@lists.grok.org.uk, bugtraq@securityfocus.com,
ntbugtraq@ntbugtraq.com
In-Reply-To: <7a282fc30512131028g40d65517k2254283bfecec6db@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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@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/
>
