Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the yeah-but-who-uses-those dept.

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

125 of 181 comments (clear)

  1. WTF is csoonline? by trifish · · 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

    1. Re:WTF is csoonline? by k(wi)r(kipedia) · · Score: 5, Informative
      Here's another link 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.

    2. Re:WTF is csoonline? by speps · · Score: 2

      The patch itself : http://marc.info/?l=git-commits-head&m=114223318030280&w=2

    3. Re:WTF is csoonline? by Relayman · · Score: 2

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

      --
      If I used a sig over again, would anyone notice?
    4. Re:WTF is csoonline? by 93+Escort+Wagon · · Score: 1

      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.

      --
      #DeleteChrome
    5. Re:WTF is csoonline? by simcop2387 · · Score: 1

      The XEN hypervisor can potentially cause all guest systems (even dom0 is a guest under XEN) to get into a problem. Redhat ships a number of products directly under XEN so that may be why they report it.

    6. Re:WTF is csoonline? by julesh · · Score: 1

      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.

  2. Besides MS and Intel... by Anonymous Coward · · Score: 2, Informative

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

    1. Re:Besides MS and Intel... by metageek · · Score: 5, Informative

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

      --
      metageek
    2. Re:Besides MS and Intel... by unixisc · · Score: 1

      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?

    3. Re:Besides MS and Intel... by drinkypoo · · 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:Besides MS and Intel... by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    5. Re:Besides MS and Intel... by Vlad_the_Inhaler · · Score: 1, 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.

      --
      Mielipiteet omiani - Opinions personal, facts suspect.
    6. Re:Besides MS and Intel... by arth1 · · 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.

    7. Re:Besides MS and Intel... by Gaygirlie · · Score: 1

      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.

    8. Re:Besides MS and Intel... by Gaygirlie · · Score: 1

      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.

    9. Re:Besides MS and Intel... by The1stImmortal · · Score: 2

      Non-E3 Xeons?

    10. Re:Besides MS and Intel... by The1stImmortal · · Score: 1

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

    11. Re:Besides MS and Intel... by Svartalf · · Score: 1

      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.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    12. Re:Besides MS and Intel... by Svartalf · · Score: 1

      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.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    13. Re:Besides MS and Intel... by kasperd · · Score: 1

      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.

      --

      Do you care about the security of your wireless mouse?
    14. Re:Besides MS and Intel... by cbiltcliffe · · Score: 1

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

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
    15. Re:Besides MS and Intel... by kermidge · · Score: 1

      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.

    16. Re:Besides MS and Intel... by redneckmother · · Score: 1

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

      Thanks for recognizing that the questions comprise a stereotype. Here's a couple of corrections to the misapprehensions:

      1) Contrary to popular belief, Texans usually don't buy "oversized" pickups. We get the one that'll do the job, and a 1/2 ton usually ain't it.

      2) Although many Texans purchase ammunition, the "consumers" of bullets are generally at the "bidness end" of the firearm.

    17. Re:Besides MS and Intel... by Riventree · · Score: 1

      Also, in the above list, how does OpenBSD do?

      OpenBSD is unaffected. They put in a return-address sanity check way back in 2004.

    18. Re:Besides MS and Intel... by drinkypoo · · Score: 1

      Agreed. I was happy to finally be able to save up and get a six-core CPU last year.

      I finally saved up and bought a six-core CPU this month... for $109 or so. Went from a 2.8GHz Phenom II X3 to a 2.7 GHz Phenom II X6. Couldn't be happier with the swap. Now I just need to get block caching on Linux to my new (open box) SSD...

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    19. Re:Besides MS and Intel... by mysidia · · Score: 1

      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 equal clock rate, except in processors of the same type.

      A 1.8 GHz CPU core that accomplishes twice as much work per clock cycle is faster than a 3GHz core.

      For example, a Quad core 1.8Ghz Intel Sandybridge faster than a 3GHz Quad core Intel Core 2 CPU.

    20. Re:Besides MS and Intel... by redneckmother · · Score: 1

      Wait, so the consumers are not Texans? Who the hell are they? People with the wrong skin color without documentation? Yankees? Californians?

      No... ACs :-).

    21. Re:Besides MS and Intel... by rrohbeck · · Score: 1

      AMD Bulldozer or Opteron. Best bang for the buck.

      --
      thegodmovie.com - watch it
    22. Re:Besides MS and Intel... by Kalriath · · Score: 1

      Don't give them ideas. More computers than you think are equipped with TPM and UEFI.

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
    23. Re:Besides MS and Intel... by drinkypoo · · Score: 1

      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.

      Well, while you have a point, there's a lot more than clock speed involved, like how many instructions can be retired in a single cycle, how many functional units the processor has, how good the branch predictor is, how big the cache is...

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    24. Re:Besides MS and Intel... by Fjandr · · Score: 1

      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 processor architecture. Intel copied it (since AMD was open with the architecture) to stay competitive, but apparently did not follow the architecture to the letter.

      Those who aren't affected escaped by virtue of not using the instruction Intel screwed up.

    25. Re:Besides MS and Intel... by galanom · · Score: 1

      Any FarmVille / CityVille / CrapVille facebook flash game easily cripples my Core 2 Duo T9600 (2.8GHz).

  3. Re:Why is this tagged linux and redhat by Anonymous Coward · · Score: 1

    RHSA-2012:0720-1

    RHSA-2012:0721-1

  4. What is the bug? by Anonymous Coward · · Score: 1

    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?

    1. Re:What is the bug? by mevets · · 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.

    2. Re:What is the bug? by Anonymous Coward · · Score: 1

      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.

    3. Re:What is the bug? by amorsen · · 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...

      --
      Finally! A year of moderation! Ready for 2019?
    4. Re:What is the bug? by unixisc · · Score: 5, Interesting
      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, 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.

    5. Re:What is the bug? by Svartalf · · Score: 1

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

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    6. Re:What is the bug? by Svartalf · · Score: 1

      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.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    7. Re:What is the bug? by TheRaven64 · · Score: 4, 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.

      --
      I am TheRaven on Soylent News
    8. Re:What is the bug? by Dwonis · · 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.

    9. Re:What is the bug? by Dwonis · · Score: 1

      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.

    10. Re:What is the bug? by unixisc · · Score: 1

      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.

    11. Re:What is the bug? by kiwix · · Score: 2

      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.

    12. Re:What is the bug? by Rich0 · · Score: 1

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

    13. Re:What is the bug? by martyros · · Score: 1

      So what exactly is the bug?

      It's complicated, which is why so many systems missed it. I did a write-up here 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. But in Intel, the fault happens in privileged mode, with OS privileges but a guest stack pointer. So if the OS doesn't check for boundary conditions (and most didn't), the guest can set the stack pointer anywhere in OS memory and cause the fault handler scribble over it.

      --

      TCP: Why the Internet is full of SYN.

  5. Score one for Vista by Likes+Microsoft · · Score: 4, Funny

    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?!
    1. Re:Score one for Vista by msauve · · Score: 5, Funny

      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
    2. Re:Score one for Vista by anss123 · · Score: 2

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

    3. Re:Score one for Vista by drinkypoo · · 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:Score one for Vista by cdrudge · · Score: 1

      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.

    5. Re:Score one for Vista by julesh · · Score: 1

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

      Mitigating Factors for User Mode Scheduler Memory Corruption Vulnerability - CVE-2012-0217
      [...]
      This vulnerability only affects Intel x64-based versions of Windows 7 and Windows Server 2008 R2.
      Systems with AMD or ARM-based CPUs are not affected by this vulnerability.

  6. Re:Why is this tagged linux and redhat by lindi · · 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 http://groups.google.com/group/qubes-devel/browse_thread/thread/248a59a1050fe9d4

  7. Does a guest know it's a guest by Gothmolly · · Score: 2

    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.
    1. Re:Does a guest know it's a guest by PlusFiveTroll · · Score: 2

      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.

    2. Re:Does a guest know it's a guest by Sponge+Bath · · Score: 3, Funny

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

    3. Re:Does a guest know it's a guest by betterunixthanunix · · Score: 1

      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.

      --
      Palm trees and 8
    4. Re:Does a guest know it's a guest by Svartalf · · Score: 1

      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.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    5. Re:Does a guest know it's a guest by 6031769 · · Score: 1

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

      --
      Burns: We're building a casino!
      McAllister: Arrr. Give me 5 minutes.
    6. Re:Does a guest know it's a guest by mysidia · · Score: 1

      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.

    7. Re:Does a guest know it's a guest by Gothmolly · · Score: 1

      The point is that a guest MAY know via device names locally, but it doesn't HAVE TO know.

      --
      I want to delete my account but Slashdot doesn't allow it.
    8. Re:Does a guest know it's a guest by Kalriath · · Score: 1

      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.

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
  8. the bazaar strikes again by marcello_dl · · Score: 4, 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...

    --
    ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    1. Re:the bazaar strikes again by Anonymous Coward · · Score: 1

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

    2. Re:the bazaar strikes again by hweimer · · Score: 4, 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 (and unstable was fixed only two days ago).

      --
      OS Reviews: Free and Open Source Software
    3. Re:the bazaar strikes again by Anonymous Coward · · Score: 1

      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.

    4. Re:the bazaar strikes again by OneMadMuppet · · Score: 1

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

    5. Re:the bazaar strikes again by caseih · · Score: 1

      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

      Fixed a long time ago.

    6. Re:the bazaar strikes again by Anonymous Coward · · 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.

    7. Re:the bazaar strikes again by petit_robert · · Score: 1

      What a nice piece of FUD...

      I run two debian based internet servers hosting dynamic sites connected to a database. Licence cost is 0, and I have 24*7 top notch support, for free, with the proper groups.

      Doing the same thing with MS software would :
      -cost me over 30 000 dollars a year to be compliant
      -force me to dramatically increase my hardware costs
      -turn my development work into a nightmare.

      I can see how some people could be bothered by Debian servers.

  9. Is this really a hardware issue? by Anonymous Coward · · Score: 1

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

    1. Re:Is this really a hardware issue? by Anonymous Coward · · Score: 1

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

    2. Re:Is this really a hardware issue? by unixisc · · Score: 1

      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.

    3. Re:Is this really a hardware issue? by arth1 · · Score: 1

      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.

    4. Re:Is this really a hardware issue? by John+Hasler · · Score: 1

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

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    5. Re:Is this really a hardware issue? by arth1 · · Score: 3, 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

      (Linux itself isn't vulnerable, but guest operating systems might be.)

    6. Re:Is this really a hardware issue? by X0563511 · · Score: 1

      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?

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    7. Re:Is this really a hardware issue? by arth1 · · Score: 1

      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
      crw-------. root root system_u:object_r:cpu_device_t:s0 /dev/cpu/microcode
      -rwxr-xr-x. root root system_u:object_r:cpucontrol_exec_t:s0 /sbin/microcode_ctl

      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.

    8. Re:Is this really a hardware issue? by mysidia · · Score: 1

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

    9. Re:Is this really a hardware issue? by X0563511 · · Score: 1

      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?

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    10. Re:Is this really a hardware issue? by Kalriath · · Score: 1

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

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
    11. Re:Is this really a hardware issue? by arth1 · · Score: 1

      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.

    12. Re:Is this really a hardware issue? by kassah · · Score: 1

      Has anyone verified that this microcode update actually fixes the issue in question?

    13. Re:Is this really a hardware issue? by arth1 · · Score: 1

      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 admin can put the microcode fix there. VMware workstation/server/fusion are not vulnerable, because they have to go through the host, which should be patchable, but Vix might be. I don't know enough about its internals :)

  10. Re:Why is this tagged linux and redhat by errandum · · 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

  11. Article by DaMattster · · Score: 4, Interesting

    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.

    1. Re:Article by Anonymous Coward · · 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

    2. Re:Article by unixisc · · Score: 1

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

    3. Re:Article by Anonymous Coward · · 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.

    4. Re:Article by julesh · · Score: 1

      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:

      Intel 64 allows SYSCALL and SYSRET only in 64-bit mode (not in compatibility mode). It allows SYSENTER and SYSEXIT in both modes.

    5. Re:Article by tlhIngan · · Score: 1

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

      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.

  12. Re:Why is this tagged linux and redhat by buchner.johannes · · Score: 4, 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.

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
  13. Not quite by ArchieBunker · · Score: 1

    http://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true

    --
    Only the State obtains its revenue by coercion. - Murray Rothbard
    1. Re:Not quite by DaMattster · · Score: 1

      http://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true

      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.

  14. Re:U.S. Computer Emergency Readiness Team (US-CERT by microbox · · Score: 1

    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.

    --

    Like all pain, suffering is a signal that something isn't right
  15. good hosting providers already patched... by TeddyR · · Score: 3, 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/

    --

    --
    Time is on my side
  16. Gateway is bad? Talk about Dell then... by etrusco · · Score: 1

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

    1. Re:Gateway is bad? Talk about Dell then... by drinkypoo · · 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, 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.'"
    2. Re:Gateway is bad? Talk about Dell then... by isopropanol · · Score: 1

      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.

    3. Re:Gateway is bad? Talk about Dell then... by Baloroth · · Score: 1

      According to Ars Technica, 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.

      --
      "None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
    4. Re:Gateway is bad? Talk about Dell then... by macs4all · · Score: 1

      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?

    5. Re:Gateway is bad? Talk about Dell then... by drinkypoo · · Score: 1

      There's two windows versions because there's two installers, just like a Linux distribution. That means you can use cheaper install media; a CD-ROM, or at least a single-layer DVD. Plus, you never have to worry about correctly detecting the architecture.

      You don't actually need to segregate your 32 and 64 bit windows programs into separate directories on Windows 7, and the only reason I can think of is so that they can have two shared dll/etc. hierarchies, with DLLs for each architecture to support binaries for each architecture. If 32 and 64 bit programs each see their respective program files folder as the correct one, then they won't shit on each other's DLLs.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Gateway is bad? Talk about Dell then... by julesh · · Score: 1

      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.

    7. Re:Gateway is bad? Talk about Dell then... by macs4all · · Score: 1

      Ok. So if devs. had followed Windows development guidelines that have existed for years and years, and located their DLLs inside their application's directories (instead of spraying them all over the Windows install), or, even better, if MS had adopted a similar packaging paradigm to OS X (where basically everything is inside of the App's "Package"), then there wouldn't be that retarded two-Program-Files directory trees?

    8. Re:Gateway is bad? Talk about Dell then... by macs4all · · Score: 1

      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 like someone with OS X development experience to explain.

    9. Re:Gateway is bad? Talk about Dell then... by drinkypoo · · Score: 1

      Well, actually, there's a shared folder inside of program files where developers are supposed to put shared DLLs, and that's what I'm talking about. And a packaging paradigm like OSX would be nice for every OS to implement, 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    10. Re:Gateway is bad? Talk about Dell then... by macs4all · · Score: 1

      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 victim, er, user, who has lost the install disks/key for some "paid" software package they BOUGHT, and then tried to move the install to another Windows box. Whereas, with OS X, with the vast majority of software, you can simply DRAG the "Package" to the new computer, move the .plist file (if you need to preserve a registration key, and which is just an XML file), and go on your merry way. And let's not even get into that hell-hole of horseshit that is the Windows Registry!

      But one thing is exactly correct: A packaging paradigm like OS X has (where installing and de-installing is often just a DRAG away; instead of being just "a drag") would be nice for every OS to implement (including the SUPPOSEDLY not-mired-in-backwards-compatibility Linuces). So why is it that Apple is the only ones who get this?

  17. Re:U.S. Computer Emergency Readiness Team (US-CERT by Anonymous Coward · · Score: 1

    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.

  18. Re:U.S. Computer Emergency Readiness Team (US-CERT by gweihir · · Score: 1

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

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  19. Flaw? Really? by jcbarlow · · Score: 1

    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?

    1. Re:Flaw? Really? by X0563511 · · Score: 1

      Occam's razor just cut deeply into your finger. You might want to put a bandage on that.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    2. Re:Flaw? Really? by PReDiToR · · Score: 1

      Yes, it has.
      Now be quiet before they come and get you like they do everyone that posts things like ... Hang on, there's someone at the d

      --

      Do not meddle in the affairs of geeks for they are subtle and quick to anger
  20. Re:U.S. Computer Emergency Readiness Team (US-CERT by Skapare · · Score: 1

    ... except if they are a government contractor.

    --
    now we need to go OSS in diesel cars
  21. Re:A movie that share the name with a good one by Skapare · · Score: 1

    You have it wrong. Agent Smith created this bug.

    --
    now we need to go OSS in diesel cars
  22. Re:A movie that share the name with a good one by X0563511 · · Score: 1

    I see that you're trying to link it to the Matrix, but beyond that... nothing. What exactly are you trying to say?

    --
    For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
  23. Is it too early to say... by Entropius · · Score: 1

    BSD is dead. CERT confirms it?

  24. OpenBSD, virtualization, etc. by Riventree · · Score: 1

    or maybe the reason is that OpenBSD does not include any virtualisation, rather than it being robust?

    Virtualization is irrelevant in this case. Just as Linux fixed this bug in 2006 (CVE-2006-0744) OpenBSD had added a check 2 years earlier, in 2004. Indeed, this is a great example of the "silly security facists slowing down the kernel with unnecessary sanity checks" paying off in spades. (This message was written on Ubuntu 12.0.4 on an AMD64, but will pass through an OpenBSD x86 firewall before getting to /.)

  25. Why NaCL is a bad idea by Anonymous Coward · · Score: 1

    One processor bug like this exploitable from NaCL native client code could lead to exploits for millions of computers before it is patched. The patch could even require interpreting NaCL code possibly at hundredths of the normal speed. It's also why WebGL is a bad idea, since the graphics card has DMA access one driver bug could be used to exploit the entire OS.

  26. flaw, what flaw ? by slick7 · · Score: 1

    It's not a flaw but a feature of the Patriot Act and the NDAA.

    --
    The mind conceives, the body achieves, the spirit manifests.
  27. How can RCX come to contain an invalid address? by dalias · · Score: 1

    My understanding is that RCX going into the SYSRET instruction contains the saved instruction pointer from when SYSCALL called into kernel-space, which should necessarily be valid/canonical if the userspace code that performed the SYSCALL was able to run. How does RCX get replaced by an invalid/noncanonical pointer? Is the return address saved on the userspace stack and modifiable from another thread with access to the same VM space while one thread is in kernelspace? Or is there some other mechanism for feeding it an invalid address? None of the discussions of the vulnerability I've seen have addressed this issue.

  28. Re:U.S. Computer Emergency Readiness Team (US-CERT by Kalriath · · Score: 1

    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.

    --
    For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
  29. Re:A movie that share the name with a good one by X0563511 · · Score: 1

    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.

    --
    For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
  30. Re: 6 year response time by martyros · · Score: 1

    The fact that it has taken 6 years to migrate this vulnerability to other systems is somewhat discouraging.

    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 return addresses on Intel EM64T CPUs", it's hard not to conclude that it was a mistake on Intel's part (at very least in documentation). They should have gone around to all the operating system vendors and told them about the vulnerability when it was first discovered in 2006, and put a note in the instruction manual stating that it's important to check the return address.

    --

    TCP: Why the Internet is full of SYN.