Message-ID: <D52FCFAE57472647956CBAEDC08DA553664BEF@av-mail01.corp.int-eeye.com>
Date: Tue Dec 13 18:18:55 2005
From: Advisories at eeye.com (Advisories)
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@...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.

Powered by blists - more mailing lists