Re: [Publicity] Draft technical blog post

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

Thanks everyone for your comments (both here and on IRC).

I've posted an updated draft, and included one inline below.  In line 
with Lars' advice, I'm going to wait until tomorrow morning for more 
comments before pulling the trigger.
Peace,
 -George


XSA-108: Not the vulnerability you're looking for

There has an unusual amount of media attention to XSA-108 during the 
embargo period (which ended Wednesday) -- far more than any of the 
previous security issues the Xen Project has reported.  It began when a 
blogger complained that Amazon was telling customers it would be 
rebooting VMs in certain regions before a specific date.  Other media 
outlets picked it up and noticed that the date happened to coincide with 
the release of XSA-108, and conjectured that the reboots had something 
to do with that.  Soon others were conjecturing 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 
additional information to ground the discussion in reality.
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.  No catchy name for 
this one.
<!--more-->

<h1>What is the vulnerability?</h1>

XSA-108 has to do with the emulation of a piece of hardware called an <a 
href=http://www.intel.com/content/www/us/en/architecture-and-technology/64-architecture-x2apic-specification.html>x2APIC</a>. 
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 implemented in earlier generations of Intel 
hardware.  (They have been implemented in hardware since the <a 
http://en.wikipedia.org/wiki/Ivy_Bridge_%28microarchitecture%29>Ivy 
Bridge</a> architecture came out in mid-2012.)  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 read memory from 
directly after the register buffer.  If that memory is not mapped, Xen 
will crash; if it is mapped, it will copy it to 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.
Unfortunately, the presence of VT support emulating the x2APIC, 
available on newer processors, doesn't mitigate the issue: it only 
implements the 64 registers actually used by real hardware at the 
moment, leaving Xen to emulate the rest of the registers.  If you access 
registers above 64, it will trap to Xen, and Xen will emulate access to 
them, allowing you to trigger the bug.
<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>chance</i> that this memory might contain memory from another VM; and 
a <i>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 juicy 
vulnerability like Heartbleed and Shell Shock 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