ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FW: [EEYEB-20050523] Windows Kernel APC Data-Free Local Privilege Escalation Vulnerability



úÁËÒÙ×ÁÅÔÓÑ MS05-055


> -----Original Message-----
> From: Advisories [mailto:Advisories@xxxxxxxx] 
> Sent: Tuesday, December 13, 2005 9:18 PM
> To: vulnwatch@xxxxxxxxxxxxx; 
> full-disclosure@xxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx; 
> ntbugtraq@xxxxxxxxxxxxx
> Subject: [EEYEB-20050523] Windows Kernel APC Data-Free Local 
> Privilege Escalation Vulnerability
> 
> 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@xxxxxxxx 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.
> 




 




Copyright © Lexa Software, 1996-2009.