back to article Intel left a fascinating security flaw in its chips for 16 years – here's how to exploit it

A design flaw in Intel's processors can be exploited to install malware beneath operating systems and antivirus – making it tough to detect and remove. "It's a forgotten patch to a forgotten problem, but opens up an incredible vulnerability," said Christopher Domas, a security researcher with the Battelle Memorial Institute, …

Page:

  1. Tom Womack

    Thanks for this interesting description of an interesting problem!

    1. boltar Silver badge

      "Thanks for this interesting description of an interesting problem!"

      Don't you mean "super-interesting" like in the article? I'm not sure if thats the Ring 0 to "very interesting"'s Ring 3 or perhaps its just another silly americanism that grates on the ears. I suppose Ring -1 would be "Awesome interesting".

      1. Mark 85 Silver badge

        Perhaps the "interesting" part is "one ring to rule them all and it's flawed".

        1. rusk123

          'minus' one ring to rule them all

      2. Fungus Bob Silver badge
        Headmaster

        perhaps its just another silly americanism that grates on the ears"

        No, definitely British. Tony Webster and David Harris-Jones were abusing the English language this way in the 1970's.

      3. asdf Silver badge

        ah that makes sense

        Errata started in 1995 eh? Wasn't that about the time the NSA quit fighting against allowing the proles in the US (see harassment of Zimmerman) to use strong open public key encryption (as opposed to pushing the Clipper chip fail they came up with)? Guess we now know why.

        1. Anonymous Coward
          Anonymous Coward

          And it's replacemet bug is?

          The next logical question is, where is the replacement bug hidden?

  2. Anonymous Coward
    Anonymous Coward

    The UBIK flaw

    And then he recognized the profile. I wonder what this means, he asked himself. Strangest thing I've ever seen. Most things in life eventually can be explained. But - Joe Chip on a fifty-cent piece?

    It was the first Joe Chip money he had ever seen.

    He had an intuition, chillingly, that if he searched his pockets, and his billfold, he would find more.

    This was just the beginning.

    1. Loyal Commenter Silver badge

      Re: The UBIK flaw

      +1 for the PKD reference. I wonder if this flaw can be manipulated by purple beams from intelligent satellites in space?

  3. Anonymous Coward
    Anonymous Coward

    a ha ha ha ha ha :(

    There have been a few debates on El Reg over the years, where the *real* nerds have pointed out that all the FOSS in the world can be compromised if the compilers are hooky.

    At which point I (and others) have logically progressed that argument and pointed out that it's no good having faith in a compiler you wrote if you are then going to run it on a chip whose architecture and firmware you hadn't had control off. To a general air of "when has a chip ever had a bug ?".

    Stories like this demonstrate that you really need to draw an arbitrary line beyond which you are forced to accept you can't ensure 100% security.

    1. Destroy All Monsters Silver badge
      Windows

      Re: a ha ha ha ha ha :(

      I throw myself into the dust as to your wisdom, Oh Anonymous Sage!

    2. Anonymous Coward
      Anonymous Coward

      Re: a ha ha ha ha ha :(

      True, but at least Linux will run on open architectures like OpenRISC, a platform that Windows will probably never colonise. So the truth is that, while there is a limit to how much we control, we control a damn sight more than any Windows user can hope for.

      We know about this flaw now, and so it's theoretically possible to guard against the possibility of exploits where possible or to replace the aging boxes affected by the flaw.

      1. Charles Manning

        re: OpenRISC

        OpenRISC... The CPU code is open, but what about the package that cooks the VHDL down to fit on the ASIC/FPGA? What about the program that writes the bitstream to the FPGA.

        Remember that's basically how Stuxnet works...

        There is no complete guarantee.

        1. Anonymous Coward
          Anonymous Coward

          Re: re: OpenRISC

          There is no complete guarantee.

          No, there isn't, but the fact remains there's a greater guarantee here than on other OSes.

          The only true guarantee is to go and build it yourself. For most of us though, we're willing to take a RISC.

      2. Charles Manning

        Re: a ha ha ha ha ha :(

        "We know about this flaw now,"

        Yes we know about it. We also know how drugs get into prisons, yet every day prisoners around the world get stoned.

        Security is like virginity and balloons: one prick and it's gone. One little vector is all you need.

        Sure Windows has more vectors, and they're likely easier to attack, but basically we have a situation that you just have to assume anyone can get to anything they want to.

        Not much different to the physical world really. Locks can be picked, cops can be bribed. Blackmail and threats will get a sufficiently determined and resourced person anything they want.

        1. Michael Wojcik Silver badge

          Re: a ha ha ha ha ha :(

          Security is like virginity and balloons: one prick and it's gone

          A sophomoric reducto ad absurdam. No one who actually studies security in any serious way would make such a statement.

          Security is not a binary condition. It's a measure of relative costs under a threat model.

        2. Alan Brown Silver badge

          Re: a ha ha ha ha ha :(

          "Security is like virginity and balloons: one prick and it's gone. One little vector is all you need."

          Which is why onion layer security is so important. Yet the world insists on egshells.

      3. TheVogon Silver badge

        Re: a ha ha ha ha ha :(

        "True, but at least Linux will run on open architectures like OpenRISC, a platform that Windows will probably never colonise."

        Only because there is no demand for it. OpenRISC doesn't really protect you from anything as there are so many other hardware and software dependencies involved.

        Windows already supports Arm, IA-32 and x64 which are by far the largest current market segments. And Windows has previously supported Alpha, MIPS, Itanium and PowerPC, so additional processor support is not a problem if there was a need for it...

        1. Alistair Silver badge
          Coat

          Re: a ha ha ha ha ha :(

          @Vogon:

          Considering the slippery slope MS has decided to start down, and the state of ALPHA MS when it was dropped, I wouldn't expect that MS will get much past putting Windows on more than one or two Arm processors. Far too many proprietary tweaks in those. I'll admit NT/2k on alpha smoked like little else I've seen run under the windows 'brella, but as it was, there was bugger all beyond the OS you could run there other than highly proprietary code (was used in OTA payment transfers app, in house software, one off case). And, yes, MS got windows running on MIPs, sadly in every case I saw, it ran off cliffs with astonishing regularity.

          1. Alan Brown Silver badge

            Re: a ha ha ha ha ha :(

            The problem with Windows NT on "other platfoms" is a tale of two cities.

            One is the NT OS (ancestry being VMS and Multics) - which is incredibly solid, has permission models which Unix can only dream of and runs just fine on other architectures

            The other is the GUI layer, which is a tangled clusterfuck combined with a sucking quagmire and throws virtually all the finer points of the OS permissions out the window.

            The fact that Microsoft tied the two together so indivisibly means that the entire mess is best avoided.

        2. Def Silver badge

          Re: a ha ha ha ha ha :(

          And Windows has previously supported Alpha, MIPS, Itanium and PowerPC...

          Xbox360 was PowerPC based, so a cut down Windows kernel was running there more recently than some of the other architectures mentioned.

        3. CFWhitman

          Re: a ha ha ha ha ha :(

          "Windows already supports Arm, IA-32 and x64 which are by far the largest current market segments. And Windows has previously supported Alpha, MIPS, Itanium and PowerPC, so additional processor support is not a problem if there was a need for it..."

          That's a rather rosy viewpoint to take of Windows cross-architecture support. Windows supports x86 and x86_64, yes. Support for anything else has to be qualified, and a lot of it was never very useful.

          Windows has had some kind of ARM support for years. It's biggest success in this area was Windows CE/Windows Pocket PC. Of course Windows CE and company wasn't really the same operating system as Windows on the desktop. It had its own set of software and not much in common other than a standard approach to the UI. It fell into obscurity with the rise of the touch UI and the operating systems that relied on that scheme for mobile devices.

          Now Windows supports ARM in a different way. It's approach this time is similar to that of Android to run common software on multiple architectures with a virtual machine or something like one. Of course that approach has its limits, but it has its advantages as well. The problem for Windows here is that there is not a lot of software that runs that way. Most of the applications for Windows, especially the popular ones, only run on X86 variants. Windows has ARM support, but not for the programs people think of when they think of Windows.

          Windows used to have Apha, MIPS, and PowerPC support back in the late nineties. However, not that many apps were ever released for those architectures (and almost all of the few that did were server applications), and Microsoft ended support. Again, the Windows applications for x86 wouldn't run on those systems. A similar situation existed for Itanium later on.

          So yes, Windows has nominally supported a number of architectures at different times, but none of them have had the applications available to make Windows a real success. At this point Windows has basically been stuck with x86 based architectures. Theoretically, if x86 based architectures were to be cancelled, then application vendors would port their applications to whatever Windows moved to. However, that is not likely to happen.

          Of course open source software tends to adjust to different architectures more easily. Most Linux applications have been compiled for a number of architectures because they are open source. This makes is so Linux has been ready for ARM, MIPS, Power, or Itanium, etc. desktops and servers for a while.

          However, this doesn't make Linux (as in GNU/Linux, the operating system) ideal for mobile devices. Right now, Android and iOS are the successes there. Will convergence ever actually happen (with Windows RT/Modern UI, Ubuntu Snappy, Android, or whatever)? I'm not sure. There are many issues to be dealt with. It seems to me that you would need to have either two sets of applications that ran on the same base, one for mobile interfaces and one for desktop interfaces, or you would need to have one set of applications that had dual interface modes.

    3. gerdesj Silver badge
      Linux

      Re: a ha ha ha ha ha :(

      " .... To a general air of "when has a chip ever had a bug ?". ... "

      You may not be aware of the CPU errata driver that loads new microcode into the CPU at boot on many OSs. So to those espousing the above - get off my lawn and back to school with you! You may be too young to remember such classics as the FDIV bug.

      All levels of a computing device, from case to application (and not stopping at the keyboard, for that matter), have bugs and design flaws in them.

      To el reg: thanks for a great article.

      1. boltar Silver badge

        Re: a ha ha ha ha ha :(

        "All levels of a computing device, from case to application (and not stopping at the keyboard, for that matter), have bugs and design flaws in them."

        Very true. However it doesn't change the fact that System Management Mode was a profoundly stupid idea, probably one of the dumbest Intel ever had. This isn't the first hack involving it and it almost certainly won't be the last.

        1. Anonymous Coward
          Anonymous Coward

          Re: a ha ha ha ha ha :(

          Why is that?

        2. John Savard Silver badge

          Re: a ha ha ha ha ha :(

          I definitely don't like the idea of placing the reserved memory area for SMM at the end of the first 512 megabytes of memory. That means that the largest array one can use on one's computer is 512 megabytes smaller than all RAM available. Although I suppose the virtual memory hardware means that memory can look contiguous when it really isn't, so this only comes up if one is turning that off for maximum speed...

      2. launcap Silver badge

        Re: a ha ha ha ha ha :(

        > " .... To a general air of "when has a chip ever had a bug ?". ... "

        > classics as the FDIV bug.

        I remember (many many moons ago) arguing with a colleague about the use of non-Intel chips (in this case AMD). He was adamant against the use of non-Intel on the basis that "Intel were the premier chipmakers and produced chips with no errors - you always knew where you were with Intel". Then the next day the news of the FDIV bug came out..

        Sadly, he didn't change his worldview even when faced with the evidence. So we carried on buying Intel-only computers despite the cost premium.

      3. Pascal

        Re: a ha ha ha ha ha :(

        "You may be too young to remember such classics as the FDIV bug"

        My favorite quote at the time - "We are Pentium of the Borg. Division is futile. Prepare to be approximated."

      4. Solmyr ibn Wali Barad

        Re: a ha ha ha ha ha :(

        "such classics as the FDIV bug"

        And F00F bug that brought processor to a grinding halt.

        www.drdobbs.com/embedded-systems/the-pentium-f00f-bug/184410555

        1. streaky Silver badge

          Re: a ha ha ha ha ha :(

          F00F was easily fixed at the OS level though.

    4. Charles Manning

      Re: a ha ha ha ha ha :(

      Quite

      Even if you have the full source code for the CPU, have you checked the compiler that then compiles the code into gates... and the software that then writes the gates to silicon.

      These days even memory controllers have CPUs and code in them. Your disk driver has 2 or 3 ARM cores in it. Got the code for them? Checked it? Checked the compilers?...

      A dma and a small state machine are all that is required to make your whole motherboard address space visible over an ethernet port. It would be an afternoon's work to hide that inside an ethernet controller.

      After a while you just have to make some assumptions like you do in the physical world.

      1. Michael Wojcik Silver badge

        Re: a ha ha ha ha ha :(

        After a while you just have to make some assumptions like you do in the physical world.

        You always, right from the beginning and at every moment thereafter, have to make assumptions about security. You have to make assumptions about everything. Descartes showed that with his "Evil Genius" thought experiment, and he's hardly the only one to have made the argument.

        The epistemological scandal is inescapable. There's no way to guarantee that you know anything with certainty.

    5. Anonymous Coward
      Anonymous Coward

      Re: a ha ha ha ha ha :(

      To a general air of "when has a chip ever had a bug ?"

      I think you must have dreamt that

    6. streaky Silver badge

      Re: a ha ha ha ha ha :(

      To a general air of "when has a chip ever had a bug ?"

      Those people are crazy, they happen all the time. I think the issue is more when has a chip had a security bug that somebody found and it hasn't been possible to mitigate it with a microcode update. I don't think it's ever happened before.

      Given the timing of the introduction and precisely where this bug is in the CPU one has to start asking themselves rationally if it was intentionally introduced and if Intel should be doing a product recall; that's the major issue here.

      1. Mpeler
        Coat

        Re: a ha ha ha ha ha :(

        That's not a bug: it's a feature...

    7. Sam Liddicott

      Re: a ha ha ha ha ha :(

      You don't actually need to draw the line, just recognize that one might be drawn...

    8. Michael Wojcik Silver badge

      Re: a ha ha ha ha ha :(

      Stories like this demonstrate that you really need to draw an arbitrary line beyond which you are forced to accept you can't ensure 100% security.

      Anonymous amateur rediscovers threat models - film at 11.

    9. Dodgy Geezer Silver badge

      Re: a ha ha ha ha ha :(

      You CAN have security - at least security against external world attacks. (Seeing that human error produces far more incidents that the most assiduous attackers, that may not be 100%.)

      All you need to do is to dig up some sand, then extract some pure silicon from it, then design your fab plant......

  4. TReko

    We've got our FBI on you

    According to Mr Snowden, this SMM exploit is/was used by our NSA friends in SOUFFLETROUGH, SCHOOLMONTANA and DEITYBOUNCE for DELL

    1. Anonymous Coward
      Anonymous Coward

      Re: We've got our FBI on you

      "used by our NSA friends in" or designed by our NSA friends for..?

    2. launcap Silver badge

      Re: We've got our FBI on you

      >SOUFFLETROUGH, SCHOOLMONTANA and DEITYBOUNCE for DELL

      Case NIGHTMARE GREEN?

      1. Destroy All Monsters Silver badge
        Alien

        Re: We've got our FBI on you

        Another software disaster as David Cameron hatched unobstructed.

      2. lawndart

        Re: We've got our FBI on you

        @ launcap

        If the Black Chamber muck about too much I'll have to get Pinky to tinker with my camera.

    3. Jack of Shadows Silver badge

      Re: We've got our FBI on you

      Now why might I not be surprised? Aside from the fact that a multi-billion dollar agency with some of the better hackers on the planet might detect it and keep it hidden since the same head mo-fo in charge is also responsible for offensive operations as well as defensive.... Hell, they probably never needed an order to make such a modification. Given the sheer complexity of systems today at the component level (software and hardware), such a vulnerability was bound to happen. Just go spelunking to find it. Which gives more credence to the accidental occurance since Intel found and fixed it.

      1. Alan Brown Silver badge

        Re: We've got our FBI on you

        "Hell, they probably never needed an order to make such a modification"

        This is far more likely.

        Giving orders for such things means that someone will blab eventuallly. Finding holes and keeping sctum means that knowledge never leaves the lab which found it.

        Remember this is the same NSA which advised against a bunch of password space not being used in the 1970s and it took 30 years for the holes in the DES algorithm behind that advice to be unearthed by civilians.

        ISTR a bunch of discussion at the time that they gave up on Clipper along the lines that they must've found a better backdoor - and in such cases where they suddenly go quiet on something I'd say that's a deliberate hint that they're not allowed to release something but civilians should be paying attention to what's NOT being said.

  5. Anonymous Coward
    Anonymous Coward

    Is this a unique or surprising issue?

    This may be an ignorant question because I have not looked in detail at Intel based architectures since 286 days but if you have the ability to run code at ring 0 aren't there other ways to access these negative levels? Anything that cna be a bus master or capable of memory writes, for example if you have access to a device with DMA capability can't you use it to write whatever you want wherever you want or does the Intel architecture prevent access to certain locations?

    1. Smooth Newt Silver badge

      Re: Is this a unique or surprising issue?

      Digital Equipment Corp made the first page of virtual memory no access in VAX/VMS, because 0 is such a special number for pointers, unused values etc. The resulting exceptions identified pointers set to null etc. Maybe hardware designers should make physical address 0 no access for similar reasons.

      1. Jack of Shadows Silver badge

        Re: Is this a unique or surprising issue?

        On the Amiga while running Enforcer, the interrupt pointer memory location 0 was remapped to internally catch null pointers. It was one thing (Mungwall and Steve Tibbets' VirusX the other two) that was run while I was screening uploads to the Amiga Fora on CompuServe. Which should explain my zero patience with null pointers even though it's my code doing the checking on x86/x64.

      2. mevets

        Re: Is this a unique or surprising issue?

        If you have the ability to reprogram the apic, you have the ability to reprogram the page tables, so this wouldn’t help.

        Most OSes do not map 0; but kernel code certainly can, even in VMS.

  6. Bob H

    Intel Media Processors

    Now I am wondering if any of Intel's CE chips used in pay TV are vulnerable to this exploit. Obviously it depends on the ability to execute privileged code to begin with but that isn't improbable.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019