Forgot your password?
typodupeerror
Intel Security Red Hat Software SuSE Windows Linux

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

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • WTF is csoonline? (Score:5, Informative)

    by trifish (826353) on Saturday June 16, 2012 @08:33AM (#40343579)

    Proper link that ought to have been in the summary instead of that csoonline link (whatever that is):

    http://www.kb.cert.org/vuls/id/649219 [cert.org]

    • by Likes Microsoft (662147) on Saturday June 16, 2012 @08:43AM (#40343615) Homepage
      XP, Win7, and Server Core are affected, but somehow, Vista isn't!
      • by msauve (701917) on Saturday June 16, 2012 @08:50AM (#40343641)
        There are a couple of people who are going to be relieved!
      • by anss123 (985305)
        The summary says "some 64-bit operation systems", but MS12-042 [microsoft.com] mentions 32-bit XP. 64-Bit XP and Vista is apparently not affected.
        • by julesh (229690)

          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.

      • by drinkypoo (153816)

        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.

        • by cdrudge (68377)

          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:WTF is csoonline? (Score:5, Informative)

      by k(wi)r(kipedia) (2648849) on Saturday June 16, 2012 @09:20AM (#40343749)
      Here's another link [xen.org] from Xen.org with a less terse description of the problem:

      So what was the vulnerability? It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMD's SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMD's spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating system's memory.

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

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

      • by Relayman (1068986)
        According to US-CERT, OS X is not affected.
      • 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.

        • by julesh (229690)

          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.

  • by Anonymous Coward

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

  • by Gothmolly (148874) on Saturday June 16, 2012 @08:49AM (#40343639)

    Say you have local access to a machine, which is a Xen guest. Does the machine KNOW it's a guest? If yes, how "virtual" is it, and if no, how would the attacker know to try the escape?

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

      • by Sponge Bath (413667) on Saturday June 16, 2012 @09:15AM (#40343725)
        This is an illegal exit. You must return to game grid. Repeat! This is an illegal exit. You must return to the grid.
      • by Gothmolly (148874)

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

        • by Kalriath (849904)

          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.

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

    • by Svartalf (2997)

      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.

      • by mysidia (191772)

        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.

    • by 6031769 (829845)

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

  • by marcello_dl (667940) on Saturday June 16, 2012 @08:58AM (#40343657) Homepage Journal

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

  • Article (Score:5, Interesting)

    by DaMattster (977781) on Saturday June 16, 2012 @09:10AM (#40343707)
    I thought it was interesting to note that the article never mentioned anything about OpenBSD. While this does not necessarily mean that OpenBSD is not vulnerable to the Intel 64-bit bug, I still find it interesting. If OpenBSD had been tested, I wouldn't be surprised if researchers found privilege escalation by exploiting said bug impossible. The OpenBSD team has spent an inordinate amount of time working to make their OS highly secure.
    • Re: (Score:3, Informative)

      by Anonymous Coward

      OpenBSD plugged this hole back in 2004.

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

      • by unixisc (2429386)
        So did OpenBSD include a patch to use SYSEXIT instead of SYSRET if the CPU manufacturer ID was Intel?
        • Re: (Score:2, Informative)

          by Anonymous Coward

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

          • by julesh (229690)

            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.

        • by tlhIngan (30335)

          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.

  • by TeddyR (4176) on Saturday June 16, 2012 @10:21AM (#40344039) Homepage Journal

    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]

  • BSD is dead. CERT confirms it?

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

"Say yur prayers, yuh flea-pickin' varmint!" -- Yosemite Sam

Working...