2010-02-10

New Hyper-V Security Vulnerability

Many eons ago there was talk about patch footprints - comparing ESXi to Hyper-V, footprints and security patches.

So today I came across this one.

Microsoft Security Bulletin MS10-010 - Important

General Information

Executive Summary

This security update resolves a privately reported vulnerability in Windows Server 2008 Hyper-V and Windows Server 2008 R2 Hyper-V. The vulnerability could allow denial of service if a malformed sequence of machine instructions is run by an authenticated user in one of the guest virtual machines hosted by the Hyper-V server. An attacker must have valid logon credentials and be able to log on locally into a guest virtual machine to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

This security update is rated Important for all supported x64-based editions of Windows Server 2008 and Windows Server 2008 R2. For more information, see the subsection, Affected and Non-Affected Software, in this section.

The security update addresses the vulnerability by correcting the way Hyper-V server validates encoding on machine instructions executed inside its guest virtual machines. For more information about the vulnerability, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information.

So what is so different about this one - I mean Microsoft release patches once a month (and in certain extreme cases - more often).

Read the fine print…

An attacker must have valid logon credentials and be able to log on locally into
a guest virtual machine to exploit this vulnerability.

From the details:

An attacker must have valid logon credentials and be able to log on locally to a Hyper-V virtual machine to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

What is the scope of the vulnerability?
This is a denial of service vulnerability. An attacker who exploited this vulnerability could cause the affected Hyper-V server to stop responding and require it to be restarted. Note that the denial of service vulnerability would not allow an attacker to execute code or to elevate their user rights, but it could cause the affected system to stop accepting requests.

What causes the vulnerability?
This vulnerability is caused by Hyper-V server incorrectly validating the encoding of specific machine instructions executed inside the guest virtual machines. Due to this lack of validation, processing of these instructions may cause the Hyper-V server application to become non-responsive.

What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could cause a user’s system to become non-responsive until the system is restarted. Note that exploitation of this vulnerability could cause the actual Hyper-V server to stop responding, including all guest virtual machines hosted by that server.

How could an attacker exploit the vulnerability?
An attacker would have to be an authenticated user in one of the guest virtual machines hosted by the Hyper-V server and would need to have the ability to execute arbitrary code on the system. An attacker could then run an untrusted executable on the system that invokes a malformed sequence of machine instructions and thereby cause the Hyper-V server to become non-responsive.

And again the importance is the details..

Note that exploitation of this vulnerability could cause the actual Hyper-V server to stop responding, including all guest virtual machines hosted by that server.

And yep..

Restart Requirement

Restart required?

Yes, you must restart your system after you apply this security update.

HotPatching - Not applicable.

Pot calling the kettle black ??

image

2 comments:

Eric Gray said...

It was clearly a huge mistake for MSFT to make a big deal about that ESX vulnerability. Something about glass houses... Not to mention it was really misleading since the exploit mentioned did not affect shipping versions of ESX.

Stu Fox said...

Eric - your security announcement says that it affected ESX 3.5 & 3.5i - which were both current versions right? So customers could have been running those in production?

http://lists.vmware.com/pipermail/security-announce/2009/000055.html

And different to have a DOS & the ability to execute code on the host I would have thought.


Disclaimer: I work for Microsoft NZ.