XSA-108: Additional Information from the Xen Project

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:

Read more

Say hello to our new website
12/05/2024

Hello Xen Community, You may have noticed something different... We've refreshed our existing website! Why did we do this? Well, all these new changes are part of an ongoing effort to increase our visibility and make it easier to find information on pages. We know how important it

Xen Project Announces Performance and Security Advancements with Release of 4.19
08/05/2024

New release marks significant enhancements in performance, security, and versatility across various architectures.  SAN FRANCISCO – July 31st, 2024 – The Xen Project, an open source project under the Linux Foundation, is proud to announce the release of Xen Project 4.19. This release marks a significant milestone in enhancing performance, security,

Upcoming Closure of Xen Project Colo Facility
07/10/2024

Dear Xen Community, We regret to inform you that the Xen Project is currently experiencing unexpected changes due to the sudden shutdown of our colocated (colo) data center facility by Synoptek. This incident is beyond our control and will impact the continuity of OSSTest (the gating Xen Project CI loop)

Xen Summit Talks Now Live on YouTube!
06/18/2024

Hello Xen Community! We have some thrilling news to share with you all. The highly anticipated talks from this year’s Xen Summit are now live on YouTube! Whether you attended the summit in person or couldn’t make it this time, you can now access all the insightful presentations