More information on OS specific vulnerabilities can be found here: http://www.scmagazine.com.au/Tools/Print.aspx?CIID=304829
Privilege escalation vulnerability on 64-bit Intel CPU hardware
11–20 of 37 posts
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#12This is old news.
Original Release date: 12 Jun 2012 | Last revised: 25 Jun 2012
yeah, ancient history
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#13Anyone got a link to a more detailed explanation of the vulnerability and how it would be exploited?
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#14Sounds like the vulnerability is in the software (the hardware works as specified): "Intel claims that this vulnerability is a software implementation issue, as their processors are functioning as per their documented specifications. However, software that fails to take the Intel-specific SYSRET behavior into account may be vulnerable."
Intel's position is disingenuous at best. The SYSRET instruction was introduced by AMD long before Intel added support for it, so it was entirely natural for people to expect that Intel's implementation would be consistent with AMD's specification. If you build a car which experiences temporal anomalies when driven at 88 miles per hour, it isn't good enough to have a line of fine print in the middle of a 1500 page ma…
I'd say blame accumulates pretty well on both sides, here. Certainly Intel should not have gratuitously changed their behavior from AMD's. On the other hand, OS code often needs to deal with CPU-specific behavior, and they definitely should have read that fine print in the middle of the 1500 page manual when implementing this code, especially when the 1500 page manual's index points to exactly that fine print for this instruction.
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#15Earlier quoted context omitted.
Intel's position is disingenuous at best. The SYSRET instruction was introduced by AMD long before Intel added support for it, so it was entirely natural for people to expect that Intel's implementation would be consistent with AMD's specification. If you build a car which experiences temporal anomalies when driven at 88 miles per hour, it isn't good enough to have a line of fine print in the middle of a 1500 page ma…
I'd say blame accumulates pretty well on both sides, here. Certainly Intel should not have gratuitously changed their behavior from AMD's. On the other hand, OS code often needs to deal with CPU-specific behavior, and they definitely should have read that fine print in the middle of the 1500 page manual when implementing this code, especially when the 1500 page manual's index points to exactly that fine print for thi…
How precisely should OS developers have read the fine print in Intel's 1500 page manual which hadn't yet been published when support for SYSCALL/SYSRET was implemented?
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#16Sounds like the vulnerability is in the software (the hardware works as specified): "Intel claims that this vulnerability is a software implementation issue, as their processors are functioning as per their documented specifications. However, software that fails to take the Intel-specific SYSRET behavior into account may be vulnerable."
The issue seems to be present in Xen, Windows, and Linuxes -- this suggests that, regardless of technicalities, Intel did something unwise. (Or at least didn't communicate effectively with software vendors)
Per http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-pr...
"Linux actually fixed the bug in 2006, with CVE-2006-0744. [ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0744 ] But the description says “Linux kernel before 2.6.16.5 does not properly handle uncanonical return addresses on Intel EM64T CPUs…”, which makes it sound like something Linux-specific. It’s therefore not surprising that it attracted little notice from other operating systems."
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#17Earlier quoted context omitted.
I'd say blame accumulates pretty well on both sides, here. Certainly Intel should not have gratuitously changed their behavior from AMD's. On the other hand, OS code often needs to deal with CPU-specific behavior, and they definitely should have read that fine print in the middle of the 1500 page manual when implementing this code, especially when the 1500 page manual's index points to exactly that fine print for thi…
How precisely should OS developers have read the fine print in Intel's 1500 page manual which hadn't yet been published when support for SYSCALL/SYSRET was implemented ?
Presumably they should have at least read it after the Intel manuals shipped. (And did Intel really ship x86-64 CPUs without corresponding manuals? Weird if so.) Now, not doing so is a completely understandable mistake, but still a mistake.
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#18They don't have AWS on the list. Were they not notified or were they not affected? Are they vulnerable now?
Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware
#19Earlier quoted context omitted.
How precisely should OS developers have read the fine print in Intel's 1500 page manual which hadn't yet been published when support for SYSCALL/SYSRET was implemented ?
Presumably they should have at least read it after the Intel manuals shipped. (And did Intel really ship x86-64 CPUs without corresponding manuals? Weird if so.) Now, not doing so is a completely understandable mistake, but still a mistake.
And did Intel really ship x86-64 CPUs without corresponding manuals? Weird if so.
As I said, SYSCALL/SYSRET were introduced by AMD. Intel introduced their first x64-64 CPUs over a year after the architecture was introduced and in use (which is why FreeBSD still uses the name "amd64" for that platform).