Slashdot Mirror
US-CERT Discloses Security Flaw In 64-Bit Intel Chips
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."
Proper link that ought to have been in the summary instead of that csoonline link (whatever that is):
http://www.kb.cert.org/vuls/id/649219
This was found by Rafal Wojtczuk who is a co-author of Qubes OS that tries to bring strong security to the desktop. http://qubes-os.org/Home.html http://groups.google.com/group/qubes-devel/browse_thread/thread/248a59a1050fe9d4
There are a couple of people who are going to be relieved!
"National Security is the chief cause of national insecurity." - Celine's First Law
No, in other words buy an AMD rather than an Intel
metageek
Read the xen link from the article. Intel throws a #GP in supervisor mode when sysretâ(TM)ing to an invalid %rip (loaded from %rcx) - invalid because reserved bits have junk in them.
Amdâ(TM)s throws it in user mode.
Intels problem is that the kernel needs to have loaded the user stack before issuing the sysret; so you can arrange your stack to gain supervisor access.
Fix is check %rcx is valid before issuing sysret.
Details from Red Hat
RHSA-2012:0720-1 & RHSA-2012:0721-1: It was found that the Xen hypervisor implementation as shipped with Red Hat Enterprise Linux 5 did not properly restrict the syscall return addresses in the sysret return path to canonical addresses. An unprivileged user in a 64-bit para-virtualized guest, that is running on a 64-bit host that has an Intel CPU, could use this flaw to crash the host or, potentially, escalate their privileges, allowing them to execute arbitrary code at the hypervisor level. (CVE-2012-0217, Important)
from the original article
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...
Finally! A year of moderation! Ready for 2019?
But then I get a slow as crap processor.
I do not think that word means what you think it means. Dollar for dollar you're getting a lot more flops out of an AMD chip, and by the way, ALL modern processors are goddamned fast by most rational standards. In terms of actually completing computing tasks that users typically perform, even a budget CPU is blinding now. It's HDD speed that holds users back today; "back in the day" that wasn't true, your HDD could feed your system data a lot faster than you could do anything meaningful with it, anything more than shoveling took ages back when we had truly simple four-stage x86s.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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, 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.
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.
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.
I think it's only arguable inside Intel's reality-distortion field. The whole point of SYSCALL/SYSRET is to create a *fast* syscall path. Requiring extra code before *every* SYSRET in order to prevent it from overwriting arbitrary memory is pretty clearly a design flaw in Intel's specification, especially since (as TFA notes) that specification was intended to be compatible with AMD's specification.