[Publicity] Draft technical blog post

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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!

 -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 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 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