Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

US-CERT Discloses Security Flaw In 64-Bit Intel Chips

timothy posted more than 2 years ago | from the yeah-but-who-uses-those dept.

Intel 181

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

cancel ×

181 comments

Sorry! There are no comments related to the filter you selected.

U.S. Computer Emergency Readiness Team (US-CERT) (-1, Troll)

Anonymous Coward | more than 2 years ago | (#40343565)

Sounds like a nice place to work
Govt agency (guaranteed job, cannot be fired, guaranteed pension, best in class benefits, though low salary atleast in India), deals with computers (so, work is play and play is work) and to top it off, you get to hack for fun AND get a cool acronym?

Re:U.S. Computer Emergency Readiness Team (US-CERT (0)

Anonymous Coward | more than 2 years ago | (#40343703)

guaranteed job, cannot be fired, guaranteed pension, best in class benefits

Got a citation for that?

Re:U.S. Computer Emergency Readiness Team (US-CERT (1)

microbox (704317) | more than 2 years ago | (#40343965)

having worked for two government agencies and three private companies, I can say that the private corporations are no better, wasting more. Both government agencies ran a very tight ship.

Re:U.S. Computer Emergency Readiness Team (US-CERT (1)

Anonymous Coward | more than 2 years ago | (#40344229)

Having worked for both the government and private companies, I can say the exact opposite. Horrible benefits, low pay, general incompetence in staff and bureaucratic road blocks making sure nothing could get fixed, all led to my making the decision to never work for a government organization again. At least a private company is only wasting its own money and not tax dollars.

Re:U.S. Computer Emergency Readiness Team (US-CERT (1)

Skapare (16644) | more than 2 years ago | (#40344835)

... except if they are a government contractor.

Re:U.S. Computer Emergency Readiness Team (US-CERT (1)

gweihir (88907) | more than 2 years ago | (#40344449)

I know some people who used to work there. You are quite wrong.

Why is this tagged linux and redhat (0)

Anonymous Coward | more than 2 years ago | (#40343569)

Why is this tagged linux and redhat

Re:Why is this tagged linux and redhat (1)

Anonymous Coward | more than 2 years ago | (#40343593)

RHSA-2012:0720-1

RHSA-2012:0721-1

Re:Why is this tagged linux and redhat (5, Informative)

lindi (634828) | more than 2 years ago | (#40343621)

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:Why is this tagged linux and redhat (4, Interesting)

buchner.johannes (1139593) | more than 2 years ago | (#40343751)

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:Why is this tagged linux and redhat (5, Informative)

errandum (2014454) | more than 2 years ago | (#40343687)

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

WTF is csoonline? (5, Informative)

trifish (826353) | more than 2 years ago | (#40343579)

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]

Score one for Vista (4, Funny)

Likes Microsoft (662147) | more than 2 years ago | (#40343615)

XP, Win7, and Server Core are affected, but somehow, Vista isn't!

Re:Score one for Vista (0)

Anonymous Coward | more than 2 years ago | (#40343627)

The exclamation mark at the end suggests you believe Vista is more secure. Don't fool yourself. It just means it doesn't support visualization as much as Windows 7 does (see VHD etc.)

Re:Score one for Vista (5, Funny)

msauve (701917) | more than 2 years ago | (#40343641)

There are a couple of people who are going to be relieved!

Re:Score one for Vista (2)

anss123 (985305) | more than 2 years ago | (#40343651)

The summary says "some 64-bit operation systems", but MS12-042 [microsoft.com] mentions 32-bit XP. 64-Bit XP and Vista is apparently not affected.

Re:Score one for Vista (0)

Anonymous Coward | more than 2 years ago | (#40344611)

The summary says "some 64-bit operation systems", but MS12-042 [microsoft.com] mentions 32-bit XP. 64-Bit XP and Vista is apparently not affected.

What you say? 64-Bit XP and Vista? Fabrications! Nonsense! We deny any knowledge of said products.

Muhammed Saeed al-Sahaf
Director Public Relations
Microsoft.

Re:Score one for Vista (2)

drinkypoo (153816) | more than 2 years ago | (#40343969)

Well, that would really be a relief to me if my 64 bit Vista machine had an intel CPU (it's got a crappy Athlon 64 L110) or if the machine had come with 64 bit Vista, which it didn't even though it has a 64 bit CPU. Thanks, Gateway.

Re:Score one for Vista (1)

cdrudge (68377) | more than 2 years ago | (#40344075)

Don't blame the manufacturer for a product that was your choice to buy. It's not like the fact was hidden or not disclosed.

Gateway is bad? Talk about Dell then... (1)

etrusco (576870) | more than 2 years ago | (#40344091)

You think this is bad? Dell did the same to me, even though my machine has (came from factory with) 4GB of RAM! And the combination of their BIOS + drivers only allow 2.9 GB of usable RAM on the default OS (Win7 32-bit)! I've seen some posts saying that you're now allowed to install a Win7 64-bit with a key from 32-bit OS, but anyway you can't just upgrade a 32-bit installation to 64-bit (you have to reinstall).

Re:Gateway is bad? Talk about Dell then... (2)

drinkypoo (153816) | more than 2 years ago | (#40344197)

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.

Re:Gateway is bad? Talk about Dell then... (1)

isopropanol (1936936) | more than 2 years ago | (#40344579)

Just did an install of some HP RP5800 desktops at an industrial site.. 8GB RAM and Win7 32b... Not sure if that was the choice of the oil company or HP though.

Re:Gateway is bad? Talk about Dell then... (1)

Baloroth (2370816) | more than 2 years ago | (#40344857)

According to Ars Technica [arstechnica.com] , you can switch between 32-bit and 64-bit with the same key. The re-install is an issue, of course, but it can be done.

Re:WTF is csoonline? (5, Informative)

k(wi)r(kipedia) (2648849) | more than 2 years ago | (#40343749)

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:WTF is csoonline? (2)

Relayman (1068986) | more than 2 years ago | (#40344833)

According to US-CERT, OS X is not affected.

Besides MS and Intel... (2, Informative)

Anonymous Coward | more than 2 years ago | (#40343581)

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

Re:Besides MS and Intel... (-1, Troll)

busyqth (2566075) | more than 2 years ago | (#40343631)

So, in other words... buy a Mac.

Re:Besides MS and Intel... (5, Informative)

metageek (466836) | more than 2 years ago | (#40343645)

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

Re:Besides MS and Intel... (-1, Troll)

beelsebob (529313) | more than 2 years ago | (#40343659)

But then I get a slow as crap processor.

Re:Besides MS and Intel... (5, Informative)

drinkypoo (153816) | more than 2 years ago | (#40343729)

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:Besides MS and Intel... (-1)

Anonymous Coward | more than 2 years ago | (#40343879)

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

AMD CPUs are cheap but have worse power usage and lower IPC.

And, no, I would still like a faster processor if I can get one. SSDs make a big performance improvement but the faster the CPU is then the faster it gets stuff done and returns to idle. You don't buy a 12-core at 3.5GHz because you're going to saturate it, you buy it because at that speed, clicking something will complete all computations and return to idle faster than the frame rate of the monitor. I.e. The CPU's 2.6GHz rating is per second which is actually just 43.33MHz Per Frame drawn to the screen at 60FPS.

Re:Besides MS and Intel... (1)

drinkypoo (153816) | more than 2 years ago | (#40343905)

AMD CPUs are cheap but have worse power usage and lower IPC.

Worse power usage as a CPU core, sure. But better power usage as a package when you compare CPU+GPU+Chipset, oh and the GPU does a hell of a lot more. I still wouldn't buy one any more because ATI is dead to me, but their all-in-one designs have excellent value-for-money (if the driver doesn't shit on you) and the system power consumption is definitely competitive.

On the other hand, my lady just got a Core i7 in a T900 on my advice, so I don't actually disagree that I want more CPU if it's feasible.

Re:Besides MS and Intel... (-1)

Anonymous Coward | more than 2 years ago | (#40344747)

You buy computers for your blowup dolls?

Re:Besides MS and Intel... (5, Interesting)

arth1 (260657) | more than 2 years ago | (#40343979)

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:Besides MS and Intel... (1)

Gaygirlie (1657131) | more than 2 years ago | (#40344061)

but I'd personally avoid CPUs with built-in graphics and coprocessors.

I'm curious now, what CPU would you buy then? All modern ARM SoCs and x86-compatible CPUs from both Intel and AMD feature built-in graphics.

Re:Besides MS and Intel... (2)

The1stImmortal (1990110) | more than 2 years ago | (#40344139)

Non-E3 Xeons?

Re:Besides MS and Intel... (0)

Anonymous Coward | more than 2 years ago | (#40344345)

The E3 Xeon is the pretend Xeon, for the 'enterprise' folk who need the Xeon sticker.

Re:Besides MS and Intel... (1)

Gaygirlie (1657131) | more than 2 years ago | (#40344047)

You don't buy a 12-core at 3.5GHz because you're going to saturate it, you buy it because at that speed, clicking something will complete all computations

That actually very much depends on whether these computations are single-threaded or not. If they are single-threaded then no matter how many cores you throw at them they'll still complete in the same amount of time, only clock speed matters in such case.

Re:Besides MS and Intel... (1)

The1stImmortal (1990110) | more than 2 years ago | (#40344157)

Or of course if disk, network or almost any other external I/O is involved

Re:Besides MS and Intel... (1)

Svartalf (2997) | more than 2 years ago | (#40344193)

No, but I'd buy a 12 core processor in my case because I WOULD do things with it that would absorb every one of them pretty well.

Re:Besides MS and Intel... (1)

cbiltcliffe (186293) | more than 2 years ago | (#40344779)

So you could play 12 copies of Crysis at the same time? Or maybe Crysis 1, Crysis 2, Doom 3, Diablo 3, Max Payne 3, Assassin's Creed 3, Something Else 3, and still have a couple of cores left over to run Adobe Flash......

Incidentally, your sig:

I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas

Does that make you a consumer of gasoline for your oversized domestic pickup truck? Or a consumer of bullets? Maybe both? :)
(I know, I know....stereotyping.... You could drive a Corolla, for all I know...)

Re:Besides MS and Intel... (-1)

Anonymous Coward | more than 2 years ago | (#40344159)

By "slow as crap" you mean it takes more than 5 seconds to boot up your illegally gotten copy of windows?

Hey, child, if you have ANY experience running anything before a dual-core CPU with your own money, then you'd know what "slow as crap" really means.

Just because you don't get 60+FPS on your specific games on a AMD chip versus a INTEL chip doesn't mean it's "slow as crap." There's more to the world than just cheating your way through CoD, you know.

Re:Besides MS and Intel... (1)

Svartalf (2997) | more than 2 years ago | (#40344183)

Actually, only compared to Intel's TOP-END. You know, that stuff that runs for about $600-1000 per CPU chip...

Only reason I bought Intel this last upgrade cycle was that Micro Center was running a sale on some of that top tier so it was priced competitively with AMD's top end. However, I'm getting the impression that part of the reason Intel's faster has more to do with shortcuts in their implementation of silicon- as is evidenced by this little boo-boo.

Re:Besides MS and Intel... (0)

Anonymous Coward | more than 2 years ago | (#40343647)

...in this particular case, yes...

Vendor Status Date Notified Date Updated
Citrix Affected - 14 Jun 2012
FreeBSD Project Affected 01 May 2012 12 Jun 2012
Intel Corporation Affected 01 May 2012 13 Jun 2012
Joyent Affected - 14 Jun 2012
Microsoft Corporation Affected 01 May 2012 08 Jun 2012
NetBSD Affected 01 May 2012 08 Jun 2012
Oracle Corporation Affected 01 May 2012 08 Jun 2012
Red Hat, Inc. Affected 01 May 2012 12 Jun 2012
SUSE Linux Affected 02 May 2012 12 Jun 2012
Xen Affected 02 May 2012 12 Jun 2012
AMD Not Affected - 13 Jun 2012
Apple Inc. Not Affected 01 May 2012 08 Jun 2012
VMware Not Affected 01 May 2012 08 Jun 2012
Debian GNU/Linux Unknown 02 May 2012 02 May 2012
Fedora Project Unknown 02 May 2012 02 May 2012

Re:Besides MS and Intel... (1)

unixisc (2429386) | more than 2 years ago | (#40343671)

In short, a Phlenom or an Opteron can run all these things just fine. Actually, this sounds like the Pentium FDIV bug. Now question is whether all 64-bit Intel chips are affected, or just some? Also, in the above list, how does OpenBSD do? And Bitrig?

Re:Besides MS and Intel... (0)

Anonymous Coward | more than 2 years ago | (#40343713)

No, dumb ass. If you really wont to protect your data use IBM's POWER7 and AIX or i operating system.

Re:Besides MS and Intel... (1, Insightful)

Vlad_the_Inhaler (32958) | more than 2 years ago | (#40343973)

If I understood things correctly, Intel processors offer two ways of doing things, AMD just the one. The one that Intel borked is the one they offer to be compatable with AMD.
Since Apple don't need to worry about their software running correctly on AMD, they presumably used the other mechanism.

Re:Besides MS and Intel... (0)

Anonymous Coward | more than 2 years ago | (#40344257)

That's why it's currently believed that Apple OS X is not vulnerable to this.

Re:Besides MS and Intel... (1)

kasperd (592156) | more than 2 years ago | (#40344465)

If I understood things correctly, Intel processors offer two ways of doing things, AMD just the one. The one that Intel borked is the one they offer to be compatable with AMD.

That's not how I understood it. AMD designed the architecture (with a lot of inspiration from the earlier 32 bit architectures). When Intel realized that their own 64 bit architecture was not taking off, but the one designed by AMD was, Intel decided to start producing AMD compatible CPUs. Intel build the CPUs to work according to the specs released by AMD. But Intel made a mistake in the implementation of some feature, which now turns out to be a security problem. It is true that there are two ways to do the same thing.

It is true that there are two ways to do the same thing. There is the old method, which is more or less the same as it was on the 386 CPUs. And there is the new method, which is designed to improve performance. But methods are part of the spec and supported by both Intel and AMD. However only Intel introduced this particular bug in the new and improved method. Now all operating systems have to go back to the old method because of this bug in the Intel CPUs.

Hopefully they can somehow detect situations where it is necessary such that we don't see a drop in performance because they need to use the slower method.

Re:Besides MS and Intel... (0)

Anonymous Coward | more than 2 years ago | (#40344169)

If only all computers were equipped with the Trusted Platform Module, or the Extensible Firmware Interface, or the Unified Extensible Firmware Interface, or ... then Microsoft and Apple could have arranged things so we could not run non-commercial operating systems, thus solving this horrible problem. They could have protected us, dammit! /sarcasm.

What is the bug? (1)

Anonymous Coward | more than 2 years ago | (#40343611)

So what exactly is the bug?
The story gives about as much information as the summary.
Apparently there is some instruction that doesn't do exactly what the amd64 specification says, but what exactly does it do?

Re:What is the bug? (5, Informative)

mevets (322601) | more than 2 years ago | (#40343649)

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:What is the bug? (1)

Anonymous Coward | more than 2 years ago | (#40343689)

Note that the bug itself (triggering GP via RIP restored outside of userspace limit) is hardly anything new and was noted in linux some time ago, see:

http://lxr.linux.no/linux+v3.4.2/arch/x86/kernel/entry_64.S#L451

Buggy implementations (Win7, XEN and FreeBSD so far) are another story, though.

Re:What is the bug? (1)

Svartalf (2997) | more than 2 years ago | (#40344201)

Which shouldn't be needed... Just because you have a workaround for bad silicon doesn't mean it's really "fixed".

Re:What is the bug? (5, Interesting)

amorsen (7485) | more than 2 years ago | (#40343695)

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

Re:What is the bug? (1)

Svartalf (2997) | more than 2 years ago | (#40344215)

It's a CPU bug and a software one. If it's supposed to be securing something and it fails to do so, it's the fault of the CPU itself, regardless of whether there's good code there or not. As for the code, yeah, they should've been doing it- but the CPU should've stood there and stopped it. Now I'm going to be leery of Intel parts (again...) because of things like this.

Re:What is the bug? (5, Insightful)

Dwonis (52652) | more than 2 years ago | (#40344363)

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.

Re:What is the bug? (2)

kiwix (1810960) | more than 2 years ago | (#40344815)

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.

Re:What is the bug? (5, Interesting)

unixisc (2429386) | more than 2 years ago | (#40343817)

From TFA

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:What is the bug? (4, Interesting)

TheRaven64 (641858) | more than 2 years ago | (#40344285)

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.

Re:What is the bug? (1)

unixisc (2429386) | more than 2 years ago | (#40344477)

Does s/w typically scan for CPU_ID? I thought that AMD and Intel had to be identical in their opcodes, b'cos guys like Microsoft would just write one program that works regardless of what it's been running on. Historically, that would put AMD at a disadvantage as long as the ISA was 32-bit, but after AMD added 64-bit instructions to its instruction set, the tables turned, and Intel had to copy them - at least on the Intel 64.

If a s/w program scans for CPU_ID, it can run that CPU's native instruction set - it needn't even be the same instruction set. For instance, if it sees IBM's CPU_ID, it could run POWER.

Re:What is the bug? (1)

Dwonis (52652) | more than 2 years ago | (#40344375)

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.

The only software fix? That's rather complicated. All you need to do is to check if rcx is non-canonical and invoke IRET instead of SYSEXIT if it isn't, which is what Linux already does. Of course, you shouldn't *have* to do this, which is why it's a bug.

Does a guest know it's a guest (2)

Gothmolly (148874) | more than 2 years ago | (#40343639)

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?

Re:Does a guest know it's a guest (2)

PlusFiveTroll (754249) | more than 2 years ago | (#40343661)

I'm guessing you've never ran virtual hosts. It's really pretty easy to tell by the hardware list. See, lots of the hardware can use virtualized drivers that would be a pretty big tip off right there. Also, at least under Xen, both Windows and Linux can run the Xen tools that do things like keep the clock in sync with the host under it.

Also, the hacker could just try to escape even if it didn't look virtual.

Re:Does a guest know it's a guest (3, Funny)

Sponge Bath (413667) | more than 2 years ago | (#40343725)

This is an illegal exit. You must return to game grid. Repeat! This is an illegal exit. You must return to the grid.

Re:Does a guest know it's a guest (1)

betterunixthanunix (980855) | more than 2 years ago | (#40343845)

Does the machine KNOW it's a guest?

Well, if you can attack system from the guest machine, then I think the answer to that question is obvious: the user can try the attack, and whether or not the attack works will determine whether or not they are in a VM.

Re:Does a guest know it's a guest (1)

Svartalf (2997) | more than 2 years ago | (#40344223)

There's a hardware list- and there's a library that can detect that you're running in a VM and which VM you're actually running in.

the bazaar strikes again (4, Funny)

marcello_dl (667940) | more than 2 years ago | (#40343657)

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

Re:the bazaar strikes again (1)

Anonymous Coward | more than 2 years ago | (#40343719)

Well... Debian probably just ran some unit tests instead of doing a massive QA initiative to ensure everything still worked.

Re:the bazaar strikes again (4, Informative)

hweimer (709734) | more than 2 years ago | (#40343741)

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:the bazaar strikes again (1)

Anonymous Coward | more than 2 years ago | (#40343839)

So that's Xen and the FreeBSD kernel. If you run the Linux kernel (which the vast majority of users do) and use any other virtualisation platform, you're not affected.

Re:the bazaar strikes again (1)

caseih (160668) | more than 2 years ago | (#40343857)

Is that the same bug? Looks like the bug that the post is talking about is here:

http://security-tracker.debian.org/tracker/CVE-2006-0744 [debian.org]

Fixed a long time ago.

Re:the bazaar strikes again (0)

Anonymous Coward | more than 2 years ago | (#40343931)

As I understand it, the bug existed in the Linux kernel a long time ago (your link) but also (and still) in the implementation of the Xen hypervisor, Win7/2k8 and some BSDs
So, while they're technically the same bug, they're at different levels.

Re:the bazaar strikes again (4, Informative)

Anonymous Coward | more than 2 years ago | (#40343957)

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:the bazaar strikes again (1)

OneMadMuppet (1329291) | more than 2 years ago | (#40343849)

Easy victory for Debian as they didn't have to do 4 weeks of regression testing, documentation, etc before it could be classed as "fixed". Perhaps the manager didn't have the option of rolling a hack out to customers, then marking all the bugs raised against it as "works for me".

Re:the bazaar strikes again (0)

Anonymous Coward | more than 2 years ago | (#40344357)

Cool story, except debian isn't accountable to anyone and can freely push regression filled updates. Also it is not fixed in Debian stable, so no, it's not corrected for the masses.

Is this really a hardware issue? (1)

Anonymous Coward | more than 2 years ago | (#40343667)

If some operating systems are not affected, doesn't that make this a software issue?

Re:Is this really a hardware issue? (1)

Anonymous Coward | more than 2 years ago | (#40343777)

That just means there is a s/w fix or work around for the h/w bug.

Re:Is this really a hardware issue? (1)

arth1 (260657) | more than 2 years ago | (#40344021)

That just means there is a s/w fix or work around for the h/w bug.

What's more interesting to me is whether there will be microcode updates from Intel. Some systems cannot have OS upgrades, because they run legacy software which isn't cost-effective to have replaced, and won't work correctly with newer OS versions.

Re:Is this really a hardware issue? (3, Interesting)

arth1 (260657) | more than 2 years ago | (#40344083)

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:Is this really a hardware issue? (1)

X0563511 (793323) | more than 2 years ago | (#40344871)

Isn't it possible for an attacker to exploit the microcode update facility to load vulnerable code back on? If you can gain enough privilege to run the tools to do so, you might be able to then get around other access controls imposed by the kernel, right?

Re:Is this really a hardware issue? (1)

unixisc (2429386) | more than 2 years ago | (#40343861)

Depends on what exactly the OS wants to support, or is supporting. As I pointed out in another thread above, the instructions in question are SYSCALL and SYSRET, which AMD used in all its instruction sets, while Intel uses it only in Intel 64. Intel, otoh, normally uses SYSENTER and SYSEXIT for a similar, if not identtical functionality.

So if an OS was written w/ only Intel CPUs in mind, and w/ SYSENTER and SYSEXIT, then at least from an initial reading of this article, they shouldn't have a problem. While that may have at one time been true during the days of 32-bit CPUs, AMD was the one who first developed the AMD 64 CPUs, and the 64-bit instructions to go w/ it. So all the early adapters of AMD64 would probably have used SYSCALL and SYSRET, which was probably why Intel supported it. It's worth remembering that at the time, Microsoft made it clear to Intel that they were supporting AMD 64 for their 64 bit Windows, and if Intel wanted its EM64 to be supported, it had to be compatible w/ them. That was a coup for AMD, and resulted in their permanent cross-licensing agreement.

As a result, the chances that any OS was written w/ only Intel 64 in mind is very unlikely. As it is, such instructions would only be invoked by compilers, and if the ones out there - be it MS Visual Studio, GCC and so on chose to use AMD 64 instructions, it probably would not be up to them, unless they happened to go out of their way to either alter the compilers, or alter the compiled results to use SYSENTER and SYSEXIT.

Note that all this assumes that the bug in question doesn't affect SYSENTER and SYSEXIT in Intel 64.

Re:Is this really a hardware issue? (1)

John Hasler (414242) | more than 2 years ago | (#40344071)

> If some operating systems are not affected, doesn't that
> make this a software issue?

Some programs were not affected by the FDIV bug; they did no floating point math. Did that make it a software "issue"?

Article (4, Interesting)

DaMattster (977781) | more than 2 years ago | (#40343707)

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.

Re:Article (3, Informative)

Anonymous Coward | more than 2 years ago | (#40343795)

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:Article (1)

unixisc (2429386) | more than 2 years ago | (#40343885)

So did OpenBSD include a patch to use SYSEXIT instead of SYSRET if the CPU manufacturer ID was Intel?

Re:Article (2, Informative)

Anonymous Coward | more than 2 years ago | (#40343989)

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.

Re:Article (0)

Anonymous Coward | more than 2 years ago | (#40343855)

But wasn't OpenBSD's security model shot to hell when informations that the canadia(british mi6) had implement back-doors to the O.S.

Hype Phail (-1)

Anonymous Coward | more than 2 years ago | (#40343763)

Yay for overblown journo-hyped-style information-free bit of press release poop. Just link to the advisory already, you quiche-eating appliance-fondling luser, you.

Linux is safe while BSD fails again... (-1)

Anonymous Coward | more than 2 years ago | (#40343783)

Why does BSD suck so bad? And what kind of loser would use it?

Re:Linux is safe while BSD fails again... (0)

Anonymous Coward | more than 2 years ago | (#40344019)

Actually as Microsoft contributions to Linux increases so does the migration away from Linux towards BSD.

Re:Linux is safe while BSD fails again... (0)

Anonymous Coward | more than 2 years ago | (#40344057)

That's the power of the GPL. Even the mighty Microsoft must contribute code. Meanwhile Apple gets rich off the work of the basement dweller neckbeards who hack BSD without paying them or even giving any code back, haha.

Re:Linux is safe while BSD fails again... (0)

Anonymous Coward | more than 2 years ago | (#40344147)

Um... really?

http://opensource.apple.com/

good hosting providers already patched... (3, Informative)

TeddyR (4176) | more than 2 years ago | (#40344039)

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]

No problem here...we use AMD (0, Redundant)

dtjohnson (102237) | more than 2 years ago | (#40344045)

This flaw apparently affects only Intel chips as the vulnerability does not exist for AMD 64-bit chips.

Flaw? Really? (1)

jcbarlow (166225) | more than 2 years ago | (#40344691)

Has it not occurred to anyone here that this (and many other "flaws") are simply the carefully designed, plausibly deniable backdoors for the next generation of Flame, Stuxnex, etc? Are you all really that naive?

A movie that share the name with a good one (1)

ntropia (939502) | more than 2 years ago | (#40344741)

They better release a fix before agent Smith finds about it...

Re:A movie that share the name with a good one (1)

Skapare (16644) | more than 2 years ago | (#40344869)

You have it wrong. Agent Smith created this bug.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>