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
"Besides Microsoft and Intel, vendors whose products are affected include Joyent, Citrix, Oracle, Red Hat and SUSE Linux, US-CERT says."
XP, Win7, and Server Core are affected, but somehow, Vista isn't!
-- Who am I? How did I get here? My God, what have I done?!
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
Say you have local access to a machine, which is a Xen guest. Does the machine KNOW it's a guest? If yes, how "virtual" is it, and if no, how would the attacker know to try the escape?
I want to delete my account but Slashdot doesn't allow it.
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.
Microsoft Corporation: Affected by the bug-
notified:01 May 2012 corrected:08 Jun 2012
Debian GNU/Linux: Affected by the bug- Unknown
notified:02 May 2012 corrected:02 May 2012
Easy victory for debian, as there was no manager who had to wonder how fixing the bug ASAP vs. schedule the fix for later could potentially affect his career...
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
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?
I thought it was interesting to note that the article never mentioned anything about OpenBSD. While this does not necessarily mean that OpenBSD is not vulnerable to the Intel 64-bit bug, I still find it interesting. If OpenBSD had been tested, I wouldn't be surprised if researchers found privilege escalation by exploiting said bug impossible. The OpenBSD team has spent an inordinate amount of time working to make their OS highly secure.
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.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
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.
I am surprised that it took this long for it to reach /.
Linode.com had already patched the items last month. During an emergency but scheduled update round (took less than 30mins per host) and most users did not notice any issues since they were given more than 7 days advanced notice of the emergency update. [linode uses XEN on intel].
http://blog.linode.com/2012/06/13/xen-security-advisories-and-how-we-handled-them/
--
Time is on my side
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
(Linux itself isn't vulnerable, but guest operating systems might be.)
Yes, same on this T900 here. And all the bundled apps install themselves along with the 32 bit Windows. Yet another fun project ahead of me. That machine needs an SSD swap anyway though so it doesn't seem like it will be that arduous a restriction... I'd have to do it anyway if I didn't want to fiddle with Partition Magic, and mine is too old to do Win7 anyway.
As for the sibling comment... yeah, I shoulda known better than to buy a gateway. The point of the story is not that I shouldn't have known better, because I should, but don't buy a gateway, or maybe don't trust that an AMD-based platform will have good support of any kind, because it may not. Indeed, this is the machine I'm always bitching about that doesn't work worth a shit with Linux. I haven't tried it in a little while though so I may give it another go.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
I am TheRaven on Soylent News
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.
I don't think anyone got the OS/hypervisor part right except by accident.
Apparently, the same bug was in the Linux kernel and has been fixed in 2006, with CVE-2006-0744. So they intially got it wrong, but fixed it before most other OS/hypervisors. It also seems that OpenBSD is not affected.