MS HyperV Persistent DoS Vulnerability

miércoles, 15 de junio de 2011

De estas se están viendo cada día más… a esto me refería en artículos anteriores donde comentaba sobre herramientas de seguridad para Hipervisores. Hoy le toca a Microsoft.

1. *Advisory Information*
Title: MS HyperV Persistent DoS Vulnerability
Advisory ID: CORE-2011-0203
Advisory URL:
Date published: 2011-06-14
Date of last update: 2011-06-14
Vendors contacted: Microsoft
Release mode: Coordinated release

2. *Vulnerability Information*
Class: Input validation error [CWE-20]
Impact: Denial of service
Remotely Exploitable: No
Locally Exploitable: Yes
CVE Name: CVE-2011-1872

3. *Vulnerability Description*
A security vulnerability was found in the driver 'vmswitch.sys', associated to the Windows Hypervisor subsystem, allowing an authenticated local DoS. The vulnerability could allow denial of service if a specially crafted packet is sent to the VMBus by an authenticated user in one of the guest virtual machines hosted by the Hyper-V server. The impact is all guests on that host became non-responsive.

An attacker must have valid logon credentials and be able to send specially crafted content from a guest virtual machine to exploit this vulnerability. As a result, an attacker logged with admin privileges on a guest VM may cause:

   1. All applications in virtual machines stop responding.
   2. The host kernel CPU usage rises up to 100%.
   3. The host machine is unable to reboot (It shows the close window but it never performs the host rebooting).

The vulnerability could not be exploited remotely or by anonymous users.

4. *Vulnerable packages*

   . Windows Server 2008 for x64-based Systems
   . Windows Server 2008 for x64-based Systems SP2
   . Windows Server 2008 R2 for x64-based Systems
   . Windows Server 2008 R2 for x64-based Systems SP1

5. *Non-vulnerable packages*
   . Windows XP SP3
   . Windows XP Professional x64 Edition SP2
   . Windows Server 2003 SP2
   . Windows Server 2003 x64 Edition SP2
   . Windows Server 2003 with SP2 for Itanium-based Systems
   . Windows Vista SP1 and Windows Vista SP2
   . Windows Vista x64 Edition SP1 and Windows Vista x64 Edition SP2
   . Windows Server 2008 for 32-bit Systems and Windows Server 2008 for 32-bit Systems SP2
   . Windows Server 2008 for Itanium-based Systems and Windows Server 2008 for Itanium-based Systems SP2
   . Windows 7 for 32-bit Systems and Windows 7 for 32-bit Systems SP1
   . Windows 7 for x64-based Systems and Windows 7 for x64-based Systems SP1
   . Windows Server 2008 R2 for Itanium-based Systems and Windows Server 2008 R2 for Itanium-based Systems SP1

6. *Vendor Information, Solutions and Workarounds*
For additional information about this issue visit the Microsoft security bulletin MS11-047 [1]

7. *Credits*
This vulnerability was discovered and researched by Nicolas Economou from Core Security Exploit Writers Team. The publication of this advisory was coordinated by Fernando Miranda from Core Security Advisories Team.

8. *Technical Description / Proof of Concept Code*
This flaw is located in the hypervisor driver 'vmswitch.sys' of Windows systems. The Proof of Concept showed in [Sec. 8.1] was tested on the latest released version 6.1.7600.16701 of the above mentioned driver.

When digging into the vulnerability, in the 0x20 position of a hypervisor packet there is a QWORD (0x3333333333333333 in the PoC) that seems to be the length of something. This value is checked in the function 'VidLockObjectShared', located in the driver 'vid.sys'. The QWORD is compared against the value 0xffeff and the function returns with error 0xC0370022 if the QWORD value is higher. Apparently, that makes some flag is not set and the package processing never ends. Unfortunately, additional and specific technical information regarding the root and nature of this vulnerability was not provided by Microsoft.

8.1. *Proof of Concept*
The following PoC would trigger the vulnerability. The PoC basically injects the functions 'handle', 'handle2' and 'packet_changer' as a shellcode, and calls to the command 'ipconfig' for generating activity in the driver of the network adapter (in order to accelerate the trigger). It was compiled using Borland C++ v5.5.1 for Win32, and should be executed under the following scenario:

   1. The guest machine must be a Windows XP with SP2 or SP3.
   2. The user running the PoC must have admin privileges.

The PoC code covers the whole kernel memory looking for a pattern of code located in the network driver 'netvsc50.sys' on the guest machine. The code is in the function 'PkSendPacketSimple' and it's a call to the function 'memcpy'.

When that pattern is located in the driver code, the entry of the function 'memcpy' is patched in the import table, redirecting this function call to the hook function 'handle', previously written by the PoC code in kernel memory. Then, when 'memcpy' is called by the driver to assemble the package to be sent to the hypervisor, the execution flow will jump to the 'handle2' function (via the hook set by the 'handle'), which is the function that receives the content of the argument passed to 'memcpy' and turns a 'Simple' type packet into a 'GpaDirect' type packet. All these steps are taken in order to trigger the vulnerability.

8.1.1. *Code*

9. *Report Timeline*
. 2011-02-03:
Core Security Technologies notifies the MSRC of the vulnerability, setting the estimated publication date of the advisory to March 1st, 2011.

. 2011-02-04:
MSRC notifies that the case 10985 was opened to track this issue and a case manager will get in contact shortly.

. 2011-02-22:
MSRC notifies that the results of their investigation indicate this is an authenticated local DoS: An admin on a guest VM can manage to cause a DoS on the host. The impact is all guests on that host became non-responsive. This issue is considered to be bulletin class, but a release date was not set yet.

. 2011-02-24:
Core notifies that the analysis made by MSRC fits with the one made by Nicolas Economou, the discoverer of the vulnerability. Core also requires specific technical information to help understand the nature and root cause of the bug, and notifies the advisory publication was re-scheduled to March 15th, 2011 waiting for a MSRC update.

. 2011-03-16:
Core notifies that two release dates were missed (March 1st and March 15th) and requests a status update and additional technical information about this issue.

. 2011-03-17:
Vendor acknowledges reception of the last email.

. 2011-03-18:
MSRC requests to set up a conference call to discuss this issue next Monday 21st.

. 2011-03-21:
MSRC asks for a conference call to discuss this issue.

. 2011-03-21:
The Core Security Advisories Team notifies their preference to maintain all the communication process via email in order to keep track of all the interactions and allow all stakeholders to take part.

. 2011-03-21:
MSRC would like to confirm that Core is declining the request to have a meeting on this issue.

. 2011-03-21:
The advisory coordinator notifies that he himself, on behalf of the Core Advisories Team, has declined the request to set up a conference call because of the previously mentioned reasons. Furthermore, the publication of an advisory usually involves several processes, triggers, people and teams in Core internal process:

   1. the discoverer of the vulnerability,
   2. researchers,
   3. exploit writers,
   4. QA and testing groups,
   5. press people, among other;

and the Core Advisories Team prefers all interactions via email in order to have a better coordination. If there is something that cannot be resolved via email, a conference call can be eventually set up, but that is not necessary at the moment.

. 2011-03-23:
MSRC notifies they could not meet the deadline for the fixes and they moved the release date from April to June 8th.

. 2011-03-31:
Core notifies that the June release seems a bit far given that this bug is very close to the MS10-020 [2] reported on Dec 14th, 2010 with the CVE-2010-3960. When working on the Hyper-V DoS reported in MS10-020, Nicolas Economou discovered a new attack vector, and it is likely that this vulnerability is already known by others. Core notifies a release date near the end of April would be more convenient.

. 2011-04-01:
MSRC notifies they are currently working with the product team to determine if this update can be pushed into May. Because of the Microsoft patch Tuesday release cadence there are only two possibilities for release of these updates: the second Tuesday in May and the second Tuesday in June.

. 2011-04-25:
Core re-schedules the advisory publication to May 10th and asks MSRC if fixes will be available by that date.

. 2011-04-25:
MSRC notifies that, due to some testing issues that occurred with the fix, the team did not meet the May deadline and will need to ship this update on June 14th.

. 2011-04-28:
Core notifies that this issue was reported on Feb 3th, and 4 publication dates were already missed:

   1. March 1st, 2011 (first tentative publication date)
   2. March 15th, 2011
   3. April 2011
   4. May 10th, 2011

The Core Advisories Team agrees to postpone the advisory publication to June 14th, but that date should be considered final. Core also asks additional information about the affected and patched versions numbers related to this issue.

. 2011-06-02:
MSRC notifies that the fix for this vulnerability is in testing but no issues have been found so far and the security bulletin is still scheduled for June 14th.

. 2011-06-14:
Advisory CORE-2011-0203 is published.

10. *References*


Con la tecnología de Blogger.