Xen has unveiled the details of a security issue in its hypervisor that forced cloud providers Amazon and Rackspace into a full reboot of all users’ affected machines over the past week.

The issue, CVE-2014-7188 / XSA-108, allowed hardware virtual machine guests to potentially read data from either other guest machines, or the hypervisor itself, Xen said in its advisory. The memory bug hit x86 systems with machines with ARM chips escaping the issue.

“The MSR [model-specific register] range specified for APIC use in the x2APIC access model spans 256 MSRs. Hypervisor code emulating read and write accesses to these MSRs erroneously covered 1,024 MSRs,” Xen said.

“While the write emulation path is written such that accesses to the extra MSRs would not have any bad effect (they end up being no-ops), the read path would (attempt to) access memory beyond the single page set up for APIC emulation.”

While the issue affects Xen 4.1 and over, a patch has been issued for xen-unstable, Xen 4.4, 4.3, and 4.2.

Over the past week, the issue has been cited as the cause for full reboots of Amazon’s cloud service, as well as Rackspace, that occurred at short notice.

Rackspace CEO and president Taylor Rhodes wrote in a blog post that the company had wrestled with the issue of needing to quickly patch systems against the need to alert customers to how and why their machines would be rebooted.

“We decided the lesser evil was to proceed immediately, at which time we notified you, and our partners in the Xen community, of the need for an urgent server reboot,” Rhodes said.

“Even then, to avoid alerting cyber criminals, we didn’t mention Xen as the reason for the reboot. Another major cloud provider did attribute its reboot to security problems with Xen, which put all users of the affected versions of that hypervisor at heightened risk.

“But we’re relieved to report that as of now, we’ve learned of no data compromise among Rackspace customers.”

Rhodes said the issue affected almost one quarter of Rackspace’s customer base of approximately 200,000.

Although the ability to read memory is severe, Joanna Rutkowska, head of the Qubes project, said in a post to Qubes development mailing list that while it looks serious in theory, it may not necessarily be as bad as expected in practice.

“The vulnerability allows to read only a few kB of the hypervisor memory, with only relative addressing from the emulated APIC registers page, whose address is not known to the attacker.” Rutkowska said.

“Much less the attacker would be able to control what structure are located there, as there doesn’t seem to be many ways of how a malicious HVM might be significantly affecting the layout of the hypervisor heap.”

She said that even if an attacker were lucky enough to find another VM’s data, it would be unclear what the VM was doing with the data at the time that it was suspended.

“It seems like exploiting this bug in an IaaS scenario might be more practical, though, as the attacker also has some control of domain creation/termination, so can affect Xen heap to some extent. But on a system like Qubes OS, it seems unlikely.

“So, are we doomed? We likely are, but probably not because of this bug.”