View Single Post
  #6   (View Single Post)  
Old 14th June 2012
thirdm thirdm is offline
Spam Deminer
 
Join Date: May 2009
Posts: 248
Default

Quote:
Originally Posted by comet--berkeley View Post
The keyword here being "VM".

All the Linux vulnerabilities seem to require XeN for the bug to appear:
It doesn't actually require Xen in general, if I'm reading the link below correctly:

http://blog.xen.org/index.php/2012/0...ge-escalation/

You'll note that Linux fixed their non-Xen version of the problem in 2006, but others apparently weren't paying close attention to what they were fixing and whether it affected them too:

https://cve.mitre.org/cgi-bin/cvenam...=CVE-2006-0744

"Linux kernel before 2.6.16.5 does not properly handle uncanonical return addresses on Intel EM64T CPUs, which reports an exception in the SYSRET instead of the next instruction, which causes the kernel exception handler to run on the user stack with the wrong GS."

Also interesting about the Xen blog description is that the motivation for the sysret instruction (and a similar one from Intel that hasn't become the defacto standard) was performance. And I find it interesting how you have the two chip vendors not agreeing on a single solution and then implementing sysret in slightly different ways causing more complexity.

So I wonder, did Linux fix it by using iretq instead or by some other means (one of the Redhat advisories says something about guard pages)? You're implying that OpenBSD weighed sysret vs. iretq, figured sysret smelled funny, and passed on the performance gain -- i.e. you're saying it was something deliberate in the OpenBSD developers' approach that saved them. That sounds plausible, but is that how it happened or did they just get lucky?

FreeBSD's advisory doesn't mention Xen, so does that mean you can get privilege escalation with them on bare hardware?

Doesn't Amazon's EC2 service use Xen?
Reply With Quote