Re: [Publicity] Draft technical blog post

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Oct 02, 2014 at 03:48:30PM +0100, George Dunlap wrote:
> Hey all,
> 
> Below is a more technical draft blog post in response to the recent media
> flurry about XSA-108.  If you've updated your blog logins you can also
> preview the post here: https://blog.xenproject.org/?p=10093&preview=true
> 
> Let me know if you have any feedback!

You might want to add that Linux guests that run in HVM mode don't enable
x2APIC mode at all - as they end up using the PVHVM route which ends up
using events.

This does affect 'true' HVM guests.

> 
>  -George
> 
> XSA-108: Not the disaster you're looking for
> 
> There has an unusual amount of media attention to XSA-108, whose embargo
> period ended Wednesday -- far more than any of the previous 107
> vulnerabilities the Xen Project has reported.  It began when a blogger
> noticed that Amazon was telling customers it would be rebooting VMs in
> certain regions before a specific date -- a date which happened to coincide
> with the release of XSA-108.  He conjectured that the reboots had something
> to do with that, and further conjectured that, because of the major impact
> to customers of rebooting, that it must be something very big and important,
> similar to the recent Heartbleed and Shell Shock vulnerabilities. Amazon
> confirmed that the reboots had to do with XSA-108, but could say nothing
> else because of the security embargo.
> 
> Unfortunately, because of the nature of embargoes, nobody with any actual
> knowledge of the vulnerability was allowed to say anything about it, and so
> the media was entirely free to speculate without any actual facts getting in
> the way.
> 
> Now that the embargo has lifted, we can talk in detail about the
> vulnerability; and I'm afraid that people looking for another Shell Shock or
> Heartbleed are going to be disappointed.
> 
> <h1>What is the vulnerability?</h1>
> 
> XSA-108 has to do with the emulation of a piece of hardware called an
> x2apic.  x2apic is an interrupt controller: it allows the operating system

x2APIC 

> to control when and how and where urgent messages from outside the chip, and
> from other cores within the same chip, are delivered.
> 
> Interrupt controllers occupy a rather awkward position in the architecture.
> They are fairly complicated to implement in hardware; which is why they are
> not yet implemented by Intel's VT hardware. (This may change in the future.)
> But they are far too performance critical for Xen to pass emulation off to
> qemu, as it does with virtual disks or virtual networks.  This means that

QEMU

> they must be emulated within Xen.
> 
> The actual vulnerability, like most vulnerabilities, is pretty simple.  Xen
> implements 256 x2apic registers.  These registers are stored in a buffer big
> enough to hold exactly 256 registers. However, the limit check for reading
> these registers was erroneosly set to 1024.
> 
> What this means is that, without the fix, if you read x2apic registers
> 0-255, you'll get the correct emulated value from the register buffer; but
> if you read x2apic registers 256-1023, Xen will copy hypervisor memory from
> directly afterwards into the guest.
> 
> So what this bug gives you is the ability to read (and only read) the 12k
> [1] of memory directly adjacent to where Xen is storing the first 256
> registers (and no other area of memory).
> 
> The fix simply corrects the limit check to 256.
> 
> The emulated x2apic functionality was introduced in Xen 4.1, so previous
> versions of Xen are not affected.  Neither are PV guests, since Xen does not
> provide them with any emulated hardware.
> 
> <h1>The impact</h1>
> 
> If this seems like a relatively minor issue, that's because it is. The most
> likely scenario is that that 12k of memory contains other Xen data
> structures which contain no important information.  There is, however, a
> <i>small chance</i> that this memory might contain memory from another VM;
> and a <i>small chance</i> that this memory might contain sensitive
> information, like passwords, encryption keys, or other private data.
> 
> Nonetheless, this <i>is</i> a security issue, and the XenProject takes all
> potential security issues very seriously, no matter how minor.  We have a
> mature <a href=http://www.xenproject.org/security-policy.html>process</a> in
> place to notify cloud providers, distributions, and software providers so
> that they can have a fix in place before publicly disclosing any
> vulnerability.
> 
> Applying security patches proactively, even though there's very low risk
> that anyone might have their secret data leaked because of it, is a
> conscientious and diligient thing to do.  We're glad to see that so many
> cloud providers using Xen are demonstrating how seriously they take
> protecting customer data.
> 
> But it is by no means a disaster.  Those looking for a major scandal like
> Heartbleed and Shellshocker will be disappointed.
> 
> 
> [1] You may see this reported elsewhere as 3k; saying either 3k or 12k is
> simplifiying the truth in different ways.  The MSR data is laid out as a
> 16-byte structure, of which only the first four bytes (one 32-bit word) can
> be read by this vulnerability.  So the actual amount of data which is
> exposed is 3k, but it's spread out in 4-byte chunks across 12k of memory.
> 
> 
> _______________________________________________
> Publicity mailing list
> Publicity@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity

_______________________________________________
Publicity mailing list
Publicity@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity