Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Intel Security

All Intel Chips Open To New 'Spoiler' Non-Spectre Attack (zdnet.com) 132

Spoiler is the newest speculative attack affecting Intel's micro-architecture. From a report: Like the Spectre and Meltdown attacks revealed in January 2018, Spoiler also abuses speculative execution in Intel chips to leak secrets. However, it targets a different area of the processor called the Memory Order Buffer, which is used to manage memory operations and is tightly coupled with the cache. Researchers from Worcester Polytechnic Institute, Massachusetts, and the University of Lubeck in north Germany detail the attack in a new paper, 'Spoiler: Speculative load hazards boost Rowhammer and cache attacks'. The paper [PDF] was released this month and spotted by The Register. The researchers explain that Spoiler is not a Spectre attack, so it is not affected by Intel's mitigations for it, which otherwise can prevent other Spectre-like attacks such as SplitSpectre.
This discussion has been archived. No new comments can be posted.

All Intel Chips Open To New 'Spoiler' Non-Spectre Attack

Comments Filter:
  • by Anonymous Coward on Tuesday March 05, 2019 @10:29AM (#58219094)

    Here we go again! I'm going to go make more popcorn.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      "So I don't think we will see a patch for this type of attack in the next five years and that could be a reason why they haven't issued a CVE."

      That's actually a silly reason not to open a CVE. A CVE is opened even before there are fixes available. It's made to track vulnerabilities.

    • Re: (Score:3, Funny)

      Here we go again! I'm going to go make more popcorn.

      Good idea- I'm going to place some unpopped kernels on my Intel CPU.

  • by j_f_chamblee ( 253315 ) on Tuesday March 05, 2019 @10:30AM (#58219098) Homepage Journal

    As opposed to spammy, pop-up filled ZDNet article.

    https://www.theregister.co.uk/... [theregister.co.uk]

    • by TFlan91 ( 2615727 ) on Tuesday March 05, 2019 @10:37AM (#58219142)

      And what should've been the summary:

      The researchers – Saad Islam, Ahmad Moghimi, Ida Bruhns, Moritz Krebbel, Berk Gulmezoglu, Thomas Eisenbarth and Berk Sunar – have found that "a weakness in the address speculation of Intel’s proprietary implementation of the memory subsystem" reveals memory layout data, making other attacks like Rowhammer much easier to carry out.

      The researchers also examined Arm and AMD processor cores, but found they did not exhibit similar behavior.

      "We have discovered a novel microarchitectural leakage which reveals critical information about physical page mappings to user space processes," the researchers explain.

      "The leakage can be exploited by a limited set of instructions, which is visible in all Intel generations starting from the 1st generation of Intel Core processors, independent of the OS and also works from within virtual machines and sandboxed environments."

      Also, in before f**k JavaScript. The researchers just chose to use this has a means to demonstrate the weakness in Intel processors, not a weakness in JS.

      • by thereddaikon ( 5795246 ) on Tuesday March 05, 2019 @10:56AM (#58219236)

        Also, in before f**k JavaScript. The researchers just chose to use this has a means to demonstrate the weakness in Intel processors, not a weakness in JS.

        Fair enough, but still fuck javascript.

      • by phantomfive ( 622387 ) on Tuesday March 05, 2019 @11:16AM (#58219346) Journal
        The problem with Javascript is that every day you allow complete strangers to run their javascript on your computer.

        Most people don't want to use no-script, but even if you don't, then it is imperative to use adblock. There is too much malware in ads otherwise.
      • by sjames ( 1099 )

        The weakness is not in JS itself, but JS from a hostile web site is the most likely vector for code that uses the flaw to attack a desktop machine.

    • by goombah99 ( 560566 ) on Tuesday March 05, 2019 @10:49AM (#58219218)

      Perhaps I've misunderstood what Rowhammer was. I thought it was a a corruption attack caused by repeated adjacent bank accesses flipping bits in another bank. Thus I thought it's intent was to corrupt the adjacent bank not read back the adjacent bank. I don't even see how the bit flipping could work in the reverse direction to leak out information.

      Yet this article seems to say it amplifies a rowhammer attacks efficiency and also can be used to spy on other processes.

      Not seeing how. So maybe I have this wrong?

      • by crow ( 16139 )

        I'm not sure either, but I would speculate that since the attack lets you find out about the memory layout, you can figure out where another application (or VM) is using memory, so you can target that memory with Rowhammer, using your own memory that has the right physical relationship on the DRAM chips. I would also speculate that you could use Rowhammer to corrupt your own memory in a way that is predictably different depending on the contents of the memory in the other application, allowing you to read

      • by DamnOregonian ( 963763 ) on Tuesday March 05, 2019 @12:25PM (#58219742)
        It's a good question. I'll answer.
        Rowhammer allows you to flip bits in memory with specific relationships to memory you can access.
        If one of the bits you're able to flip happens to be bits in a page table, and enough stars line up, allows you to flip access bits on pages you're interested in, the MMU will let you read them as you will. Meltdown addresses this problem by completely swapping out the kernel pagetables between context switches.
        However, if even more stars line up, then you can potentially map pages back in.
        Leaking information about the page tables does make that a much faster process.
        To be clear: Rowhammer is a problem on all CPUs. This accelerates the speed at which Rowhammer can try to brute force a page table entry.
        • thanks. that makes sense.

          I've wondered as well why cpu makers don't try to trap these problems with process oversight rather than prevent them. For example, Rowhammer is the use of the memory in a way that exceeds memory specs. You could say the same was true if somehow it was causing overheating or excess current draw. It exceeds specs. We have temperature monitors and current monitors to catch and shut down those two. So why not a monitor that detects rowhammer's spec exceeding aspects? I can't say

          • by Anonymous Coward

            All heuristic scanning processes have this same problem. In a general purpose device you simply can't classify things as weird or abnormal because new software can do all sorts of new and weird things. That leaves you with pattern recognition wack-a-mole looking for specific attacks. Proactive vs reactive. It is very hard to be proactive here which is not to say its impossible. I imagine the engineer that figures out a way to do it is going to become well funded.

      • by sjames ( 1099 )

        Rowhammer is indeed a bit flipping attack. The idea here is that if you can figure out the physical page layout, you can make a better guess about what bits you might like to flip in the page table to make a R/O page R/W or to map a physical page you shouldn't see into your address space.

        It's still a 'statistical' attack. It won't always work before something else flips and crashes the machine.

  • by mandark1967 ( 630856 ) on Tuesday March 05, 2019 @10:37AM (#58219140) Homepage Journal
    Intel's committment to backward compatiblity
  • by phantomfive ( 622387 ) on Tuesday March 05, 2019 @10:40AM (#58219156) Journal
    Quoth the article:

    The researchers say that Spoiler improves Rowhammer attacks and cache attacks that reverse-engineer virtual-to-physical address mapping. Using Spoiler, they show the leakage can be used to speed up reverse-engineering by a factor of 256. It also can speed up JavaScript attacks in the browser.

    It's not clear that this vuln allows you to attack anything by itself, but being able to speed up Rowhammer shows why you need to take vulnerabilities seriously, even if you can't figure out how to exploit them.

    • by AmiMoJo ( 196126 )

      Rowhammer lets you steal data from other tasks and the OS. That's why it's so useful for reverse engineering - you can get at protected OS data like the executable code or crypto keys, and use that to develop further exploits.

      For example the PS3 security was broken when someone did a glitch attack to allow them access to protected OS memory, dumped the OS and found a USB exploit that could be then used without the glitch. Rowhammer just allows the glitch to be done in software from user-land, where as the o

  • That speculative execution as a concept is flawed and insecure. Or at least the way it is understood today. Perhaps new implementations need to be developed or potentially we should just abandon the concept altogether and accept our CPUs will be a bit slower.
    • You will see roughly 1/5th the performance, if you eliminate all speculation and OOO Execution.
      (Which means 1/5th the battery life in a mobile device.)

      The notion that giving up speculative execution is a reasonable option is deeply flawed.

      We need to fix it so that information cannot leak via timing attacks.

      Practically speaking we may only be able to reduce the bit rate of the leaks to something very slow, and in combination increasing the size of the secrets we are trying to protect. This will have the effe

      • I think 1/5th the performance is over stating it a bit. There will be an impact but we are realistically looking at more like 25%. CPU's didn't magically get 5x faster when OOO execution was introduced.
      • We can have fast CPUs with speculation execution and all of that, and all of the same security for private keys you'd get with a simple, slow CPU.

        An Intel Core i9 is good for transcoding video and cost $500.
        An Intel 8051 is secure for handling encryption keys and cost $1.
        If you can afford the $500 Core i9, you can afford to add the equivalent of an 8051 for the most security sensitive stuff like generating and handling encryption keys.

        That's what chips like the DS5250 are for. They don't have speculative ex

    • by lgw ( 121541 )

      That speculative execution as a concept is flawed and insecure.

      It's great as a concept, and there's nothing about the concept that's inherently insecure. It was just implemented with a blind unconcern for security that isn't really excusable in any project that started after 2000 or so.

      • by HiThere ( 15173 )

        Sorry, but I must disagree. Inherent in the concept of speculative execution on a CPU is a more complex CPU design, and this means that the chance of design error is vastly increased. Now consider just how difficult it is to write a bug-free program, and how much more difficult it becomes as the complexity of the program increases. Then consider that you can't really do an exhaustive test of a CPU within the lifespan of the universe.

        All that said, either these "bugs" are intentional, or Intel have been e

        • by gweihir ( 88907 )

          I am with "Intel has been exceedingly careless" here. Their tech has been inferior to AMD for quite some time, all they have (had) is better speed. And I think they pushed that one advantage without care and mercy.

    • by gweihir ( 88907 )

      It is not really fundamentally flawed. It need care both in its implementation and on the side of the coders using it and there needs to be special support to do some things non-speculatively, but it well can be and will remain part of any fast CPU. This is not so different from other speed-enhancing technologies. The main problem here is that Intel seems to have stopped caring at all a long time back and went to speed as the only goal and AMD had to follow at least partially to get reasonable speeds. But t

    • Is it speculative execution that is the problem or backtracking? What if we were to pull the speculative execution out of the time domain and put in parallel in space? If we were to include multiple pipelines in the same core, we could speculatively execute multiple branches in parallel and just dump all but the good one when we find out which is right. Then do a single cycle copy of all stages of the good pipeline over all pipelines to resync. With completely separate HW, there would be no potential for on

    • by sjames ( 1099 )

      The concept is fine (in some cases even mathematically provable). It doesn't become a problem until you try to push beyond what you can actually get away with or worse, knowingly cut corners and hope nobody notices.

      • Maybe I misunderstand the issue but I thought the problem had more to do with the physics of the hardware and less to do with any mathematical model the system was based upon.
        • by sjames ( 1099 )

          It's not a matter of physics really, other than the speed of light and the size of the components on the die preventing us from just speeding up a simple serial processor with a TB of RAM as fast as cache on die.

          Modern CPUs do their best to work around those limitations through pipelining, speculative execution, and speculative memory operations. The principal being that as long as the actual resulting computation once the speculations are all retired (either incorporated into the result or discarded) is in

  • by Zorro ( 15797 ) on Tuesday March 05, 2019 @11:03AM (#58219288)

    Obsidian and Flint never had these problems. Maybe we SHOULD go back to being Cavemen.

  • by Gravis Zero ( 934156 ) on Tuesday March 05, 2019 @11:12AM (#58219322)

    Buy an AMD chip and motherboard.

    • Re: (Score:2, Insightful)

      by willaien ( 2494962 )

      AMD has had some speculative execution attacks that are viable against them, and there's probably undiscovered/undisclosed ones.

      The correct answer is: don't run untrusted code, even from websites. Come up with better (slower) execution environments that enforce timings.

      • by Anonymous Coward

        Sure there are undiscovered ones, but you can't put that on the same plate as lots and lots of DISCOVERED ONES. There are no AMD POC's. Stop spreading FUD.

    • AMD (and also ARM) chips still suffer from most of the Spectre issues, though I agree somewhat, they're fewer than in Intel chips.
      • by HiThere ( 15173 )

        No. They suffer from SOME Spectre errors. Not most. And the ones they suffer from are more difficult to implement.

        Most of the errors, and especially most of the ones that are (relatively) easy to implement, are Intel specific.

        That said, AMD has it's own "management engine". Not good.

        • As of 2018, AMD chips are also vulnerable to Spectre1 and Spectre2 [techarp.com], only Intel has Meltdown alongside these issues. As for now much more Spectre types have been discovered [thehackernews.com] and this list keeps growing. Many Intel, AMD and ARM chips are vulnerable.
          • by Anonymous Coward on Tuesday March 05, 2019 @02:31PM (#58220540)

            In a word, wrong. AMD is not cross-process vulnerable without another vuln at RING-0, you can only attack in-process. That makes it much less useful - you need to have an existing hacked process to get THAT PROCESS data.

            With intel you can get ANY process data from ANY OTHER PROCESS, even in VM's. It's not comparable. This article is a NEW, additional attack that makes it even more trivially exploited.

            FTFY

      • by gweihir ( 88907 )

        They have a part of the issues, but they also come with it being a lot harder to exploit than on Intel, on some so hard that it is not even clear whether they can be exploited at all. (No such doubts on Intel). Denying that AMD now has a significant security advantage is just blind.

        • Why people misunderstand me. I just said that AMD has many of the issues that Intel has, they are somewhat fewer but they exist. Did you miss this?

          I agree somewhat, they're fewer than in Intel chips.

          AMD has some advantages (such as not having Meltdown, but as far as I know only Linux dynamically toggles this mitigation, not sure about MacOS) but it still has many Spectre type issues. Some people might prefer AMD chips because of this.

          • by gweihir ( 88907 )

            I did not miss your statement. While AMD has some of the Spectre type issues, they are far harder to exploit on Intel due to implementation differences, to the point that some researchers doubt they can be practically exploited on AMD at all. To be fair, they are already pretty hard to exploit on Intel.

      • Even Intel doesn't believe this. If they did, they wouldn't have so desperate to combine the Spectre and Meltdown issues into one announcement and jump the gun on the announcement in order to obfuscate the fact that their exposure to these problems was and is much greater.
    • by Misagon ( 1135 ) on Tuesday March 05, 2019 @01:41PM (#58220244)

      The researchers had tested only an AMD processor of the previous generation: Bulldozer.
      It is still unknown if Zen is susceptible to this attack or not.

      • by Anonymous Coward

        But you can bet that Intel spent all of the 90 days trying to get it to fail on AMD Zen too so that they could muddy the waters with a press release and try to blame AMD too. So chances are very good AMD has no problem with this one.

        • Exactly how would that be muddying the waters? It's fair to point out that issues affecting your system affect your direct competitors, too.

  • by Suren Enfiajyan ( 4600031 ) on Tuesday March 05, 2019 @11:28AM (#58219426)
    Modern computing becomes so disappointing. New and new security issues are discovered in CPUs and the software becomes more and more inefficient after each mitigation without the full benefit of the speed of the modern hardware. I wonder if we'll the point where it will be more practical just not to optimize hardware in some ways anymore since more problems are created than solved.
    • by ReneR ( 1057034 )
      that's why I still stick to my Sgi Octane (w/ Linux): https://www.youtube.com/watch?... [youtube.com] and when performance does not matter, a SPARCstation 2 https://www.youtube.com/watch?... [youtube.com] ;-)!
    • by HiThere ( 15173 )

      It's already past that point. But the simpler chips aren't manufactured with modern techniques.

      The better approach would be massively multi-processor chips with drastically simpler CPUs. Say something similar to the M68000, only also with 64 bit words. You'd need to add a few instructions to facilitate passing immutable messages between the CPUs on the chip. (Is CPU even the correct term?) And each CPU would need it's own cache. A couple of the CPUs would be processed for I/O handling (PPUs?).

      Unfortuna

      • Or maybe let the software, such as JS engine or OS kernel, to turn off certain optimizations but still benefiting from many others.
    • What problem is being created? Our lives are a constant battle of benefits vs downsides. If we cared truly deeply about security we wouldn't be here talking right now with our valuable computers exposed to a foreign network.

      Yet we've accepted that risk for the benefit we get. Likewise most people who care about speed will disable Specter mitigation due to the incredibly tiny likelihood of it yielding a successful exploit in most end user scenarios.

      Conversely there are some people out there who should defini

  • Seriously, soon nothing left that is secure, and performance all gone all over the place :-/!
    • by sinij ( 911942 )
      I could only assume you are not serious when conflating research into discovering vulnerabilities and existence of vulnerabilities. Wait, are you serious?
  • Its like a game to find out what deals the NSA has made with chip makers.

    • There's no need for the NSA to have a flaw such as this when you have an entire "Management Engine" on the chip.

  • Interesting how this much-maligned, and all but dead, processor architecture remains immune to these attacks.
  • bonus points if you remember these

Every successful person has had failures but repeated failure is no guarantee of eventual success.

Working...