US-CERT Discloses Security Flaw In 64-Bit Intel Chips 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."
WTF is csoonline? (Score:5, Informative)
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 (Score:4, Funny)
Re:Score one for Vista (Score:5, Funny)
Re: (Score:3)
Re: (Score:2)
MS12-042 is a package with fixes for three unrelated flaws. Details for this particular flaw are hidden under "Vulnerability Information" / "User Mode Scheduler Memory Corruption Vulnerability - CVE-2012-0217":
Re: (Score:2)
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:2)
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.
Re: (Score:2)
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, b
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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).
I'm REALLY not trolling or flamebaiting; but I'd love to know why Apple can seamlessly integrate 32 and 64 bit "stuff" while running the same CPUs as other PC manufacturers; but with Windows at least, they can't even keep them in the same Applications folder (WTF is with the Program Files, and Program Files(x86), anyway?), and has to have two completely separate OSes to properly use 64 bit?
I mean, we're going to be caught between a 32 and 64 bit world for quite a bit; why cause all this pain for the user?
Re: (Score:2)
Just making a wild guess: because OSX has an executable format designed to cope with varying CPU architectures, and can therefore stuff both 32-bit and 64-bit versions of a library in a single file, while other systems need to have separate files for each version, resulting in both Windows and Linux having separate directory hierarchies (Program Files + Program Files (x86), or /usr/lib + /usr/lib64 under linux) to ensure libraries for one arch don't get loaded by programs for the other.
Re: (Score:2)
Just making a wild guess: because OSX has an executable format designed to cope with varying CPU architectures, and can therefore stuff both 32-bit and 64-bit versions of a library in a single file, while other systems need to have separate files for each version, resulting in both Windows and Linux having separate directory hierarchies (Program Files + Program Files (x86), or /usr/lib + /usr/lib64 under linux) to ensure libraries for one arch don't get loaded by programs for the other.
I think it goes deeper than that. Living in the Mac world, I can tell you there is NO "I must get the "Universal" (or 64 bit) version of such-and-such driver because I just got a 64 bit Mac". You just don't see that, period. And I have personally upgraded several Macs that had third-party drivers that did NOT get "replaced" or "updated" during the upgrade.
So, I'm back to my original question: Why is everyone else experiencing a data-width schism but Apple? Again, not flamebaiting or trolling; just would l
Re: (Score:2)
Re: (Score:2)
but here's the rub; Windows couldn't load two different versions of a DLL at once unless they had different names until Windows XP.
So, in other words, since for over a DECADE? XP is only one year "younger" than OS X, and, in case you haven't noticed, TWO major Windows OS releases ago (well, 1 1/2; since Visturd was more of a bad joke than an actual "release"). So what's the holdup?!?
Fuck, MS deprecates and churns through their own "standards" like NOBODY else; so why do they allow developers to continue using "packaging" (if one can call spraying DLLs all over, "packaging") methods that are so arcane and user-hostile? Ask any Windows
Re:WTF is csoonline? (Score:5, Informative)
A little note there offers further anecdotal "proof" about the robustness of OpenBSD:
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
OpenBSD and Linux were not vulnerable. Linux actually fixed the bug in 2006, with CVE-2006-0744.
Either you're talking about the wrong vulnerability, or Xen.org is wrong. Red Hat has already said this bug affects at least some of their products - and specifically refers to the Xen hypervisor.
Re: (Score:2)
Either you're talking about the wrong vulnerability, or Xen.org is wrong. Red Hat has already said this bug affects at least some of their products - and specifically refers to the Xen hypervisor.
This is a bug in CPU exception handling. Xen handles such exceptions itself, then reflects them to the necessary guest OS if required. The fact that Linux is secure doesn't mean Xen will be, even if Linux is the running guest.
Besides MS and Intel... (Score:2, Informative)
"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... (Score:5, Informative)
No, in other words buy an AMD rather than an Intel
Re:Besides MS and Intel... (Score:5, Informative)
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... (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: (Score:2)
Re: (Score:2)
Re: (Score:2)
AMD Bulldozer or Opteron. Best bang for the buck.
Re: (Score:2)
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.
Huh? Of course speed of the CPU is important. IO capacity and memory speed matter. On modern CPUs there is no FSB directly relating CPU clock rate to IO system clock rate; this is a function of separate memory controllers and memory speed which have their own GHz rating and for PCIe IO, CPU GT/s rating, and a quantity of banks per CPU.
Now speed does not
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Agreed. I was happy to finally be able to save up and get a six-core CPU last year. All cores are set to run BOINC for WCG work. Works well; I've been able to contribute more work units in just the past six months than in the previous seven years combined. Plenty of cores for VMs, a game; and yes, I'd like more.
For lots of stuff, the more cores, the merrier.
Re: (Score:2)
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: (Score:2, Insightful)
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: (Score:2)
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
Re: (Score:2)
All the x86-64 procs incorporate all the instruction sets by both AMD and Intel that exist at the time they are developed, with the possible exception of whatever brand new extension each has incorporated into their newest generation of processors. If by "second way" you mean Intel's collaboration with HP, no, those instructions don't run on Intel's x86-64 procs. It's an entirely separate and incompatible architecture. It's also been dying slowly since the day it was released. AMD created the modern 64-bit
Re: (Score:2)
Re: (Score:2)
Don't give them ideas. More computers than you think are equipped with TPM and UEFI.
Does a guest know it's a guest (Score:3)
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: (Score:3)
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 (Score:4, Funny)
Re: (Score:2)
The point is that a guest MAY know via device names locally, but it doesn't HAVE TO know.
Re: (Score:2)
You'll be able to tell via hardware device IDs (PCI Vendor ID, etc) regardless. Otherwise, it's certain there will be low level calls that allow limited communication with the hypervisor - enough to know it's there (it's how Xen/VMWare/Parallels tools know they're running on a supported VM).
So yes, the guest DOES have to know.
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
By default hypervisors do not attempt to hide their existence.
Hypervisors do have options to hide the fact that a machine is running in a VM, but then you can't use paravirtualized drivers or VM guest tools.
Re: (Score:2)
As others have explained an instance can tell if it's a guest or a host, but it cannot distinguish between being a guest on a host and being a guest on a guest on a host. If you think that sounds crazy, you should really watch "Inception".
the bazaar strikes again (Score:5, Funny)
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 (Score:5, Informative)
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: (Score:2)
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 (Score:4, Informative)
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: (Score:2)
Article (Score:5, Interesting)
Re: (Score:3, Informative)
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: (Score:2)
Re: (Score:2, Informative)
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: (Score:2)
In long (64-bit) mode, Intel provides SYSRET and not SYSEXIT in order to conform to AMD's spec.
I believe you are incorrect. They provide both instructions in long mode, but only SYSEXIT in 32-bit compatibility mode. Wikipedia puts it this way:
Re: (Score:2)
No, they just check to make sure the address being returned into is canonical (i.e., won't cause the fault) so no fault is generated by hardware to begin with. If not, throw some big nasty exception that kills the process (it would've caused an exception anyway so you save the exception overhead).
Interesting bug with a really trivial patch to fix it.
Not quite (Score:2)
http://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true [linuxjournal.com]
Re: (Score:2)
http://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true [linuxjournal.com]
That was old news. A code audit of the IPSEC sub-system was performed by Theo de Raadt and no backdoors were found. Instead, a few bugs were fixed. It isn't a good idea to keep FUD that has been disproven alive.
good hosting providers already patched... (Score:4, Informative)
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]
Is it too early to say... (Score:2)
BSD is dead. CERT confirms it?
flaw, what flaw ? (Score:2)
Re: (Score:1)
RHSA-2012:0720-1
RHSA-2012:0721-1
Re:Why is this tagged linux and redhat (Score:5, Informative)
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 (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:Why is this tagged linux and redhat (Score:5, Informative)
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:What is the bug? (Score:5, Informative)
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: (Score:2)
Which shouldn't be needed... Just because you have a workaround for bad silicon doesn't mean it's really "fixed".
Re: (Score:2)
To be honest, I think it's because Intel screwed up but didn't own up. If you look at the description of the 2006 Linux fix, it makes it sound like it was somehow Linux's fault; when Linux's code works just fine to the AMD specs. Intel's instruction was supposed to be a copy of the AMD instruction. If every single operating system vendor, independently, managed to "not properly handle uncanonical re
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...
Re: (Score:2)
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? (Score:5, Insightful)
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: (Score:2)
Yup, and I expect that the end result of this is that I as an AMD CPU owner will have to watch all my hypervisor code get a little slower so that Intel doesn't have to do a recall on their equipment.
Perhaps it would be a bit much to ask anybody implementing it a patch to make it configurable for those building on AMD...
Re: (Score:3)
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? (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: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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
It's complicated, which is why so many systems missed it. I did a write-up here [xen.org] with the gory details.
In short, the instruction is executed by the OS to return to user mode. Under certain conditions, this may throw a general protection fault. In AMD this fault happens in user mode. Happening in user mode is safe, so many OSes, designing to the AMD spec and assuming Intel's was the same, weren't checking boundary conditions to make sure that what the user was giving it was OK.
Re: (Score:2)
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. W
Re: (Score:2)
> 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"?
Re: (Score:2)
If some operating systems are not affected, doesn't that make this a software issue?
If your hard disk randomly garbles odd numbered sectors in a certain address range near the end of the disk, you won't lose any data if you have an OS that only writes to even numbered sectors, and only partitions the first half of the disk.
Other OSes will experience data corruption.
It's still a hardware issue. This does not mean that operating systems that fully utilize all disk sectors presented by the hardware
Re: (Score:2)
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? (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: (Score:2)
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: (Score:2)
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?
$ ls -Z /dev/cpu/microcode /sbin/microcode_ctl /dev/cpu/microcode /sbin/microcode_ctl
crw-------. root root system_u:object_r:cpu_device_t:s0
-rwxr-xr-x. root root system_u:object_r:cpucontrol_exec_t:s0
So you need to both be root and (with SElinux) also run in a context type with write access to cpu_device_t, like cpucontrol_exec_t.
Re: (Score:2)
Ah, thanks for looking. So to even bother you already have to own the box.
What about virtualization? I know that stuff like VMWare/Virtualbox shouldn't be vulnerable because (i think) you can't talk to the CPU directly like that. What about things like Xen? If you can, might it be a vector out of the VM and into the host?
Re: (Score:2)
What about virtualization? I know that stuff like VMWare/Virtualbox shouldn't be vulnerable because (i think) you can't talk to the CPU directly like that. What about things like Xen? If you can, might it be a vector out of the VM and into the host?
As far as I can tell from the kernel sources, Xen has its own microcode snippet in the kernel, which only allows microcode updates from Dom0 (the "primary" vm with full hw access), not any of the DomU guests. So that should be safe too, unless they've done something stupid like forwarding the requests from DomU to Dom0...
VMware "bare metal" hypervisors might be vulnerable to the original bug, but not to abusing the microcode interface, unless they now allow access to the hidden Linux hypervisor so the admi
Re: (Score:2)
The first think I see is that Intel only releases Linux microcode updates. I assume for Windows, they ask Microsoft to deploy them via Windows Update. Which means 2000 and lower will remain vulnerable unless Microsoft releases an out-of-support update (which they won't).
Re: (Score:2)
The first think I see is that Intel only releases Linux microcode updates. I assume for Windows, they ask Microsoft to deploy them via Windows Update. Which means 2000 and lower will remain vulnerable unless Microsoft releases an out-of-support update (which they won't).
Right, which is one reason to run older OSes virtualized if possible - the host system can take advantage of patches that also benefits the guest OS, like firmware fixes and microcode.
Re: (Score:2)
Re: (Score:2)
... except if they are a government contractor.
Re: (Score:2)
I know some people who used to work there. You are quite wrong.
Re: (Score:2)
I would for a government agency. Our jobs are the most unstable there are (layoffs once or twice a year), no superannuation plan, no benefits, low salary, and generally it's just shit. I only stay there because I like the team I work with.
Re: (Score:2)
You have it wrong. Agent Smith created this bug.
Re: (Score:2)
I see that you're trying to link it to the Matrix, but beyond that... nothing. What exactly are you trying to say?
Re: (Score:2)
Well, I got that you were linking it to the matrix in some way ("agent Smith" and your subject) but I don't understand how it relates to the story at all. That critical link is missing from your post.
Re: (Score:2)
Occam's razor [wikipedia.org] just cut deeply into your finger. You might want to put a bandage on that.
Re: (Score:2)
Now be quiet before they come and get you like they do everyone that posts things like