Date: Tue, 12 Oct 2004 21:45:50 -0700
From: "Derek Soeder" <dsoeder@...e.com>
To: <bugtraq@...urityfocus.com>
Subject: EEYE: Windows VDM #UD Local Privilege Escalation


Windows VDM #UD Local Privilege Escalation

Release Date:
October 12, 2004

Date Reported:
March 18, 2004

Severity:
Medium (Local Privilege Escalation to Kernel)

Systems Affected:
Windows NT 4.0
Windows 2000
Windows XP (SP1 and earlier)
Windows Server 2003

Description:
eEye Digital Security has discovered a third local privilege escalation
vulnerability in the Windows kernel that would allow any code running on
an affected system to elevate itself to the highest possible local
privilege level (kernel), regardless of the privileges with which the
code executes initially.  For instance, a malicious user with legitimate
access to a machine, or a remote attacker or worm payload able to gain
unprivileged access through an unrelated exploit, could leverage this
vulnerability to fully compromise a Windows NT 4.0, Windows 2000,
Windows XP, or Windows Server 2003 system.

This vulnerability is located in a portion of the Windows kernel that
handles some low-level aspects of executing 16-bit code inside a Virtual
DOS Machine (VDM).  A certain invalid opcode byte sequence is used in
the 16-bit DOS emulation code to pass requests (referred to as "bops")
to the 32-bit VDM "host" code, and the invalid opcode fault handler
within the Windows kernel gives these sequences special treatment when
relaying them to the 32-bit host code executing in user space (normally
an NTVDM.EXE process).  The kernel does not validate the address to
which execution is transferred after one of these invalid instructions
is encountered, and because the memory containing the address is fully
accessible to user-mode code, it is possible to redirect execution to an
arbitrary location with kernel privileges still in effect.

[NOTE: This vulnerability was silently fixed by Microsoft in June,
approximately 90 days after it was reported, with the release of Windows
XP SP2 Release Candidate 2.  All other versions of Windows remained
unpatched for over 120 additional days.]

Technical Description:
The interrupt 06h (#UD) handler in NTOSKRNL.EXE contains a branch of
code for quickly handling C4h/C4h machine code byte sequences according
to the control word specified in the two bytes that follow, when the
sequence occurs in Virtual-8086 mode (bit 17 of EFLAGS is set).  If a
control word value other than 4250h or 4350h (both used for fast file
I/O) is given, the "bop" is passed off to another section of code in the
process hosting the VDM.  In NTVDM.EXE, this transition normally
corresponds to returning from a call to NtVdmControl(0)
(VdmpStartExecution), but in actuality, execution can be redirected
anywhere, since the switch is just accomplished by swapping out context
structures.  The VDM TIB (arrived at by way of
[[[[FFDFF124h]+44h]+1DCh]+98h] on Windows 2000, FS:[F18h] on Windows NT
4.0, Windows XP, and Windows Server 2003) is used to hold a copy of the
V86-mode context in effect at the time the fault occurred (at offset
+CD0h on NT4 and 2000, +2D8h for XP and 2003), then the context for
resuming execution of the host code is retrieved (from offset +A04h on
NT4 and 2000, +0Ch on XP and 2003) and loaded into the appropriate
registers.

As mentioned above, this context is contained in user memory but is not
sanitized in any way by the #UD handler, so any process with or without
a formally-initialized VDM can place arbitrary values in the host
execution context and get the handler to IRETD to any CS:EIP, allowing
kernel privileges to be retained while user-supplied code is executed.
On any version of Windows, it is sufficient to modify the VDM TIB in a
process with a properly initialized VDM (most easily done by code
executing in a .COM file).  For Windows NT 4.0, XP, and 2003, it is only
necessary to set the pointer at offset F18h in the user-land TIB to
reference a fake VDM TIB, then execute V86-mode code using NtContinue().

Since this advisory is really dry and jargony, we have to throw in
something a little off-beat.  We leave you with this:

T: Hey man, what're you reading?

N: Listen to this -- it's an advisory written by eEye in the
first-person.  I am Jack's LDT; without me, Jack could not emulate his
legacy DOS applications like Doom on NT.

N: There's a whole series of these:  I am Jill's null pointer.  I am
Jack's kernel--

T: Yeah, I get exploited, I completely compromise Jack in such a way
that necessitates a total system reinstallation.

Hope that clears things up.  (With apologies to Chuck Palahniuk.)

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/MS04-032.mspx

Credit:
Derek Soeder

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/index.html

Greetings:
Dedicated to

R. B. G.
1913 - 2004

An honest, humble, pious man, who worked hard for all he had, and who
dearly loved and was loved dearly by his family and community.  A great
man, for whom Heaven must surely be.

Once we've run out of tears and learned to live again, forever, we will
miss you.

Copyright (c) 1998-2004 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 e-mail
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 with regard to this information. In no event shall the
author be liable for any 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