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

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.

Comments

Here we go again!

[Anonymous Coward]

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

Re:Here we go again!

[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:Here we go again!

[Oswald McWeany]

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.

Actual Link to Register Article

[j_f_chamblee]

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

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

Re:Actual Link to Register Article

[TFlan91]

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.

Re:Actual Link to Register Article

[thereddaikon]

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.

Re:Actual Link to Register Article

[phantomfive]

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.

Re:Actual Link to Register Article

[sjames]

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.

It's nice to see

[mandark1967]

Intel's committment to backward compatiblity

Effective from Javascript

[phantomfive]

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.

Re:Effective from Javascript

[AmiMoJo]

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 original PS3 hack required physically disrupting the memory bus address lines.

Please explain the rowhammer relationship

[goombah99]

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?

Re:Please explain the rowhammer relationship

[crow]

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 the other application's data.

It all sounds very difficult to make serious use of, but the difficulty of mitigating it makes it a good target for someone who has the resources to make a serious effort.

Re:Please explain the rowhammer relationship

[DamnOregonian]

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.

Re:Please explain the rowhammer relationship

[goombah99]

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 exactly what that would be but it seems like a rate counter on bank accesses would probably tell you if a bank is being accessed faster than it can be sustainably refreshed. Heck you could even just have a wimpy capacitor that gets read every time the bank is accessed that is guaranteed to deplete before the one storying actual data deplete. So you should be able to detect this right on the memory chips themselves I should think.

That way you don't have to slow things down trying to prevent this in microcode. It's ahardware problem and seemingly a cheap fix. Everyone would buy ram that was rowhammer proof.

Re:Please explain the rowhammer relationship

[sjames]

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.

Back To The Abacus.

[Zorro]

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

Re:Back To The Abacus.

[Fly Swatter]

Pretty sure the Abacus is vulnerable to the table shake attack. Also anyone walking by can see your current value.

There is an immediate fix:

[Gravis Zero]

Buy an AMD chip and motherboard.

Re:There is an immediate fix:

[Misagon]

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.

Re:There is an immediate fix:

[RhettLivingston]

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.

Flawed HW+ inefficient SW = disappointment

[SurenEnfiajyan]

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.

Re:Flawed HW+ inefficient SW = disappointment

[HiThere]

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

Unfortunately, this approach would require redesigning most software. Whoops!

Don't issue a CVE

[mschaffer]

Instead of issuing a CVE they should be issuing a "spoiler alert".

Reminder - BULLSHIT

[Anonymous Coward]

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

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

There is nothing similar in AMD land, and no, there are no functional POC's right now for AMD. ARM yes. Malware waves use POC's that exist, not ones that don't.

Re:Reminder - BULLSHIT

[Anonymous Coward]

With regard to THIS type of attack, AMD is not vulnerable. It's 1:1 a result of Intel's specific instructions. With regard to Spectre, there is a POC for "in-process" corruption on AMD, but critically NOT CROSS-PROCESS.

That really is a key distinction. You'd have to run the exploit IN the process you're trying to get data OUT of. This makes it a PURE EDGE POC, it cannot be readily exploited without other at-level vulns. And since we're talking about CPU Ring-0 process security, other vulns that would allow that would allow ANYTHING else, and doing a Spectre attack in such an environment would be a waste of time as you already have your hooks in.

Intel's problem is that ANY process (even in VM's!) can access ANY other process's memory despite all mitigations, and then on top of that in Spectre, we have this new way of simply jumping through their front door register methodology.

ARM has similar cross-process issues, though different from Intel, and without this new Intel-specific attack in this article.

Short story - Intel is borked. They need to rewrite the way EVERYTHING works under the hood. AMD took a more sanitary approach and either got lucky, has yet to be exposed as swiss cheese, or is actually more secure.

We don't know which of those three is the case because we're not 100% through this entire case study, but either way given the state of POC's that exist NOW, comparing these vulns on AMD to Intel is just not a 1:1 and not close.

You can't have a malware wave without a POC, public or secret. If there are public POC's for trivially unlocking Intel methods, and none such for AMD, that's not comparable.

Re:Intel engineers should seriously consider suici

[lgw]

all because Intel wanted to win the megahertz war of the late '90s.

That's exactly the opposite of true. Speculative execution is entirely about "get the most done with each clock cycle", the opposite of ramping up clock cycles meaninglessly since little gets done on each.

Re:Intel engineers should seriously consider suici

[gweihir]

And it is also possible that AMD just fucked up a lot less than Intel. Remember that technologically, AMD has been ahead for quite a while (e.g. integrated memory controller, far better multi-core support, etc.), just speed-wise they lagged behind. We do now know where Intel got a significant part of that speed. So while AMD will have some vulnerabilities, it is quite possible that they have a lot less and that what they have is often a lot harder to exploit. This is the verdict on Spectre and Meltdown and there are good reasons to believe this is not an accident, but a systematic difference.

Re:I'm starting to think

[gweihir]

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 that there are serious dangers here was clear a long time ago and it was discussed in CPU conferences wayyyy back.

DO NOT MAKE FALSE EQUIVOCATIONS PLEASE.

[Anonymous Coward]

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

Re:Intel engineers should seriously consider suici

[sjames]

Possibly, but so far, Intel HAS shown more flaws, more serious flaws, and a bigger performance hit from the mitigations.