Most open source projects, Xen.org included, do what is called “coordinated disclosure” of security problems. The idea is that we keep security bugs secret until people have had a chance to patch. This blog post kicks off a discussion on how to evolve Xen.org’s security vulnerability process.
I wanted to thank everybody who submitted a proposal to speak for XenSummit. This year we had the most submissions we ever had. The XenSummit PMC will have its first meeting later this week: we are hoping that we will be able to announce the XenSummit program in the first week of July. This may be a tall order though, as we will have togo through a lot of very good proposals.
The Xen Security team recently disclosed a vulnerability, Xen Security Advisory 7 (CVE-2012-0217), which would allow guest administrators to escalate to hypervisor-level privileges. The impact is much wider than Xen; many other operating systems seem to have the same vulnerability, including NetBSD, FreeBSD, some versions of Microsoft Windows (including Windows 7), and possibly Apple OSX.
So what was the vulnerability? It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMDâ€™s SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMDâ€™s spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating systemâ€™s memory. This blog will explore the technical details of the vulnerability.
This is a guest blog post by Georg DÃ¶rn, a long-time system administrator and open source enthusiast. Georg founded his company its-doern in 2008, to develop solutions for customers entirely…