Privilege escalation vulnerability on 64-bit Intel CPU hardware

http://www.kb.cert.org/vuls/id/649219

by HerrMonnezza • 14 years ago

62 35 14 years ago

kb.cert.org

mspeed• 14 years ago

This is old news.

jps359• 14 years ago

Original Release date: 12 Jun 2012 | Last revised: 25 Jun 2012

yeah, ancient history

j_s8• 14 years ago

While perhaps a link would have been better, this was fixed in Linux in 2006.

maayank• 14 years ago

Sounds 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."

atmz• 14 years ago

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)

caf• 14 years ago

FreeBSD also.

j_s8• 14 years ago

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."

cperciva3• 14 years ago

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 manual. People expect to be able to drive a car at 88 miles per hour without ending up in the wrong century, and you should either not violate that assumption or have really big warning signs.

mikeash7• 14 years ago

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.

ikonst• 14 years ago

Date Public: 12 Apr 2006 ?!

__alexs• 14 years ago

I believe that is referring to this http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-074...

Estragon2• 14 years ago

Anyone got a link to a more detailed explanation of the vulnerability and how it would be exploited?

flatline3• 14 years ago

http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-pr...

Estragon2• 14 years ago

Thanks.

sirlancer• 14 years ago

More information on OS specific vulnerabilities can be found here: http://www.scmagazine.com.au/Tools/Print.aspx?CIID=304829

spullara• 14 years ago

They don't have AWS on the list. Were they not notified or were they not affected? Are they vulnerable now?

wwkeyboard• 14 years ago

I believe they use Xen. (and so thinks wikipedia http://en.wikipedia.org/wiki/Amazon_Web_Services)

jaylevitt• 14 years ago

AWS says no:

http://aws.amazon.com/security/security-bulletins/xen-securi...

Privilege escalation vulnerability on 64-bit Intel CPU hardware

Related Stories