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

WTF is csoonline?

[trifish]

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 [cert.org]

Besides MS and Intel...

[Anonymous Coward]

"Besides Microsoft and Intel, vendors whose products are affected include Joyent, Citrix, Oracle, Red Hat and SUSE Linux, US-CERT says."

Re:Why is this tagged linux and redhat

[lindi]

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 [qubes-os.org] http://groups.google.com/group/qubes-devel/browse_thread/thread/248a59a1050fe9d4 [google.com]

Re:Besides MS and Intel...

[metageek]

No, in other words buy an AMD rather than an Intel

Re:What is the bug?

[mevets]

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.

Re:Why is this tagged linux and redhat

[errandum]

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

Re:Besides MS and Intel...

[drinkypoo]

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.

Re:the bazaar strikes again

[hweimer]

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

According to Debian's security tracker, the stable version is still vulnerable [debian.org] (and unstable was fixed only two days ago).

Re:WTF is csoonline?

[k(wi)r(kipedia)]

Here's another link [xen.org] from Xen.org with a less terse description of the problem:

So what was the vulnerability? It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMD's SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. 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.

A little note there offers further anecdotal "proof" about the robustness of OpenBSD:

It seems that 64-bit versions of NetBSD, FreeBSD, and Microsoft Windows 7 were all vulnerable; Apple OSX may be vulnerable as well. OpenBSD and Linux were not vulnerable. Linux actually fixed the bug in 2006, with CVE-2006-0744.

Re:Article

[Anonymous Coward]

OpenBSD plugged this hole back in 2004.

http://old.nabble.com/CVE-2012-0217%3A-SYSRET-64-bit-operating-system-privilege-escalation-vulnerability-on-Intel-CPU-hardware-td34003925.html

Re:the bazaar strikes again

[Anonymous Coward]

Both are the same issue.
Please note however, the Parent is the Debian/Linux bug, GP is the debian/freebsd & xen bug.

Debian/Linux has completely resolved this, but Debian using freebsd or Xen has not completely resolved it for all versions.

Re:Article

[Anonymous Coward]

In long (64-bit) mode, Intel provides SYSRET and not SYSEXIT in order to conform to AMD's spec. The problem at hand is that Intel's implementation of that instruction under virtualization handles one kind of exception differently than does AMD's.

good hosting providers already patched...

[TeddyR]

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/ [linode.com]