The Xen Project Security Team today disclosed details of the Xen Security Advisory 108 / CVE-2014-7188 (Improper MSR range used for x2APIC emulation). The Xen Project does not normally comment on specific vulnerabilities other than issuing security advisories. However, given wide interest in this case, we believe it is helpful to provide more context. The recent Shellshock bug in Bash and the Heartbleed bug in OpenSSL last spring have put a spotlight on software security issues. Due to the proximity of the Shellshock bug and announcements of maintenance reboots from some cloud service providers, there was substantial speculation about XSA-108 among bloggers, tweeters, and reporters. For the Xen Project Security Team, XSA-108 started as a security issue like any other, but this speculation quickly turned an ordinary bug fix into an extraordinary event.
A Technical Overview of XSA-108
XSA-108 was caused by a bug in the emulation code used when running HVM guests on x86 processors. The bug allows an attacker with elevated guest OS privileges to crash the host or to read up to 3 KiB of random memory that might not be assigned to the guest. The memory could contain confidential information if it is assigned to a different guest or the hypervisor. The vulnerability does not apply to PV guests.
Why Security Matters
Managing vulnerabilities and bug fixes is par for the course in any software code base. All software has bugs, and some bugs have security implications. Hypervisors play a critical role in the security of many systems; therefore, the Xen Project community has collaboratively developed a mature and robust process for handling security problems. The Xen Project Security Team works with organizations that meet criteria set by the community to protect users, while limiting the risk that a security vulnerability can be used by an attacker.
A Unique Open Source Security Process
The Xen Project developed its Security Policy to:
- Encourage people who find security issues to report them in private.
- Enable software vendors who distribute Xen Project software, public cloud and hosting providers and large scale users of Xen Project Software to address an issue in private such that risk of exposure to their users is minimized.
The current version of our security policy was established through an open community collaboration, which focused on issues of fairness between large and small vendors while controlling the distribution of sensitive information.
We believe that no other open source community has established a security process and policy as open and transparent as ours. As a result, the policy meets the demands of multiple stakeholders all with very different needs.
We believe that the process has been working well, as it did for XSA-108. Several cloud providers updated their servers, something that they decided was necessary in this case to best ensure their users were not put at risk. Most likely smaller vendors have done the same. Product vendors and Linux distributions will make updates available to their users following the embargo date.
But as we have learned from open source software development, there is always room for improvement through proposing changes and discussing their merits.
Lessons Learned
The speculation around XSA-108 highlighted a number of areas where we can improve. For example, we may need to adjust how we handle a sudden influx of applications to join the Xen Project Security pre-disclosure list. Also, the security policy could be clarified to ensure all members on the pre-disclosure list better understand what’s expected of them during the embargo period.
As pointed out earlier, our security process has worked extremely well for the last three years and has protected users of Xen Project software. This also holds true in this case. Software and service providers have been able to prepare updates in advance of disclosure and, consequently, users are more secure.
What’s Next?
We also need to recognize that public interest in software security and vulnerabilities will likely continue, if not increase. Next week, we will start an open discussion on our mailing lists, to make any necessary adjustments to our security process in light of pressure exerted on vendors as well as community members during the embargo period for XSA-108.
Additional Information:
- Xen Project Security Response Process (includes information about joining the Xen Project pre-disclosure list)
- List of Xen Project Vulnerabilities
- Articles related to the community consultation that led to v2.0 our Security Response Process: [1], [2] and [3]