|
News News regarding BSD and related. |
|
Thread Tools | Display Modes |
|
|||
Intel CPUs affected by VM privilege escalation exploit
From http://h-online.com/-1616866
Quote:
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
||||
@J65nko, I know you are trying to keep our small community informed, and I appreciate the effort.
Please, check multiple sources -- and then focus on applicability to the BSD operating systems -- before deciding to post these sorts of news links. When I post a response in your news threads it is sometimes because I feel either your excerpt, or, the linked article itself are either incomplete or not in a useful context for BSD users.This thread is a case in point. The vulnerability also affects NetBSD. I have not seen an official notification or response listed, but it has been posted on OpenBSD's misc@ that this does not affect OpenBSD. |
|
|||
who's not proud of being puffy ?
|
|
|||
Security Intel CPUs affected by VM privilege escalation exploit
Quote:
All the Linux vulnerabilities seem to require XeN for the bug to appear: http://www.kb.cert.org/vuls/byvendor...&SearchOrder=4 A virtual machine is no more secure than the underlying host operating system. I wish a group with the mind-set of OpenBSD (or more stringent) would create a decent open source virtual machine environment... |
|
|||
Quote:
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? |
|
|||
This is a better link: http://dl.packetstormsecurity.net/08...-emulation.txt
|
|
|||
The article mentioned Windows, Linux, and FreeBSD, but sysret was also patched in Illumos 18 hours ago.
|
|
||||
Quoting myself, for correction
Quote:
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Hardware DragonFly BSD developer finds hardware bug in several AMD CPUs | J65nko | News | 3 | 8th April 2012 12:28 PM |
Differences in processing in POWER CPUs. | Ninguem | General Hardware | 5 | 25th August 2011 03:30 PM |
Super-secret' debugger discovered in AMD CPUs | J65nko | News | 3 | 16th November 2010 12:58 AM |
Zero day exploit for Firefox 3.6 | J65nko | News | 1 | 19th February 2010 06:58 PM |
portability to allegedly byte compatable but non-i386 CPUs | jimbus | FreeBSD Installation and Upgrading | 2 | 23rd September 2008 04:03 AM |