US-CERT Discloses Security Flaw In 64-Bit Intel Chips 181
Posted
by
timothy
from the yeah-but-who-uses-those dept.
from the yeah-but-who-uses-those dept.
Fnord666 writes "The U.S. Computer Emergency Readiness Team (US-CERT) has disclosed a flaw in Intel chips that could allow hackers to gain control of Windows and other operating systems, security experts say. The flaw was disclosed the vulnerability in a security advisory released this week. Hackers could exploit the flaw to execute malicious code with kernel privileges, said a report in the Bitdefender blog. 'Some 64-bit operating systems and virtualization software running on Intel CPU hardware are vulnerable to a local privilege escalation attack,' the US-CERT advisory says. 'The vulnerability may be exploited for local privilege escalation or a guest-to-host virtual machine escape.'" According to the article, exposed OSes include "Windows 7, Windows Server 2008 R2, 64-bit versions of FreeBSD and NetBSD, as well as systems that include the Xen hypervisor."
Re:What is the bug? (Score:5, Interesting)
Quote from Red Hat bug 813428:
"On Intel CPUs sysret to non-canonical address causes a fault on the sysret instruction itself after the stack pointer is set to guest value but before the CPL is changed. Systems running on AMD CPUs are not vulnerable to this issue as sysret on AMD CPUs does not generate a fault before the CPL change."
It is arguable whether it is a CPU bug or an OS/hypervisor bug. The CPU should not run the fault code with privileges, but on the other hand the OS should prevent the fault code from being called in the first place. AMD got the CPU part right, Intel didn't. I don't think anyone got the OS/hypervisor part right except by accident. Red Hat Enterprise Linux 4 is not exploitable due to the way it limits task virtual memory to 511 GB. VMWare doesn't use sysret, so that isn't exploitable either.
I wonder what VIA Nano does...
Article (Score:5, Interesting)
Re:Why is this tagged linux and redhat (Score:5, Interesting)
Qubes looks like a smart idea!
A useful feature that could be built on Qubes is to allow users to install and update programs from the repo -- because of the isolation, there is no harm for other users or root, and it doesn't clutter the system or require the admin to intervene.
For mainframe computers, where multiple users work and need access to software packages, this would be useful, and solve the issue of breaking other, incompatible programs through updates.
Re:What is the bug? (Score:5, Interesting)
The flaw stems from the way the CPUs implement error handling in their version of the SYSRET instruction, which is part of the x86-64 standard defined by Advanced Micro Devices, according to the Xen community blog. "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."
Reading the wiki article on Differences b/w Intel 64 and AMD 64 [wikipedia.org], Intel 64 allows SYSCALL and SYSRET only in 64-bit mode (not in compatibility mode). It allows SYSENTER and SYSEXIT in both modes. AMD64 lacks SYSENTER and SYSEXIT in both sub-modes of long mode.
As a result, anything written w/ binary compatibility in mind would have to support SYSCALL and SYSRET - using SYSENTER and SYSEXIT would lock the code to Intel, but make it unusable on AMD. The result I'm guessing is that most compilers are written to use SYSCALL and SYSRET rather than SYSENTER and SYSEXIT, and since Intel has not implemented these 2 correctly, OSs that use them would have trouble on Intel platforms, but not on AMD.
I'm guessing the only software fix here would be that if the software in question can detect that it's running on Intel, rather than AMD CPUs, it needs to substitute SYSENTER for SYSCALL and SYSEXIT for SYSRET, and run, until Intel fixes it in its next CPU spin. Unless of course Intel has implemented them badly as well.
Re:Besides MS and Intel... (Score:5, Interesting)
The CPU's 2.6GHz rating is per second which is actually just 43.33MHz Per Frame
Hz means "per second". Your first statement is a superfluous pleonasm, while the second doesn't make sense at all.
Anyhow, these days the internal speed of the CPU isn't as important as the interface to the outside world, including both RAM and bus access speeds.
In pre-Core days, AMD had an advantage with overclocking/underclocking CPU and RAM in sync, where on Intel chips you had to adjust the multiplier or the externally controlled RAM would get out of sync. These days, Intel over/underclocks well too - although they don't have a "black edition", and only engineering samples (ES) are fully unlocked.
AMD can still be good value for the money, but I'd personally avoid CPUs with built-in graphics and coprocessors. And what's best for one job might not be so for another job. Buy based on needs, not what gives the most power. Remember that we aren't all driving V12 engines either.
Re:Is this really a hardware issue? (Score:4, Interesting)
And to answer my own question, it does appear that Intel has a microcode update dated 2012-06-06. The Linux version is at http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21385 [intel.com]
(Linux itself isn't vulnerable, but guest operating systems might be.)
Re:What is the bug? (Score:5, Interesting)
The result I'm guessing is that most compilers are written to use SYSCALL and SYSRET rather than SYSENTER and SYSEXIT
Compilers never emit either instruction, because the source languages don't provide a system call mechanism. This code appears in hand-written assembly stubs in libc. A typical libc will contain multiple versions of the system call function for x86 (SYSCALL, SYSENTER, int 80h) and will install the correct one depending on the CPUID results.