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.
Here we go again! (Score:5, Funny)
Here we go again! I'm going to go make more popcorn.
Re: (Score:2, Insightful)
"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.
Don't issue a CVE (Score:5, Funny)
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.
Actual Link to Register Article (Score:5, Informative)
As opposed to spammy, pop-up filled ZDNet article.
https://www.theregister.co.uk/... [theregister.co.uk]
Re:Actual Link to Register Article (Score:5, Informative)
And what should've been the summary:
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 (Score:5, Insightful)
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: (Score:2)
It's definitely loose
Re: (Score:2)
"The big push for JS is trying to pass processing demand off from the cloud to client devices and make fancier UI interactions."
Yes, I do believe this was what he was referring to. Javascript can also be used for server-side dynamic content but interaction web application interfaces and that "UI Interaction" is the primary niche nothing else has filled well. Which is a shame because javascript is a horrible bastardized beast of a language but it is true nonetheless.
Re: (Score:2)
Re: (Score:2)
Technically he is wrong but there is an area of web-based application interaction and communication that isn't done well by other solutions, hence the lack of any other placeholder accepted by the market to fill it.
Re: (Score:2)
Re: (Score:1)
Re:Actual Link to Register Article (Score:4, Insightful)
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 (Score:1)
How about Privacy Badger? Does that one block malware too, or only tracking cookies?
Re: (Score:3)
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.
Re: (Score:2)
Never attribute to malice that which can be explained by stupidity.
It would surprise me if a junior engineer at some point during the development of each ... and then was told to
culpable feature set raised his hand and said "you know, this is a slippery slope we are
heading down here that could lead to cross-process exploits."
sit down, shut up, and get the layout for the ancillary peripheral bus controller validated
under PSPICE and let the senior engineers worry about the big stuff... because after
all we hav
Please explain the rowhammer relationship (Score:4, Informative)
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: (Score:3)
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
Re:Please explain the rowhammer relationship (Score:5, Informative)
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: (Score:3)
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
Re: (Score:1)
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.
Re: (Score:3)
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.
It's nice to see (Score:5, Funny)
Re: (Score:1)
Effective from Javascript (Score:5, Insightful)
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: (Score:3)
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
Reminder - BULLSHIT (Score:3, Insightful)
"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,
Re: (Score:2)
While your quote is correct, the Grandparent's point was that Intel has been more heavily studied than AMD or ARM, and thus it may be that different attacks of equivalent severity exist for those architectures.
And he's right, but they sure aren't known to exist. Where attacks are known to exist, Intel is either equally vulnerable, more vulnerable, or the only one vulnerable. (Well, OK, I overstate the point. Sorry. Yes, there have been a few attacks specific to the AMD or ARM.)
Re: (Score:3, Insightful)
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
Re: (Score:2)
"some of these attacks" = the various speculative execution attacks, not the exact attacks in the article, numbnuts. My point was that this is a much further reaching issue than just some handful that have been found in Intel chips. This problem of leaking data via various speed enhancements type of attacks will probably be more widespread than we currently realize, and saying "don't buy intel, buy AMD because it's safe" is a naive and dangerous mindset to be in for this. We should be taking steps to mitiga
Re:Intel engineers should seriously consider suici (Score:4, Insightful)
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: (Score:3)
Possibly, but so far, Intel HAS shown more flaws, more serious flaws, and a bigger performance hit from the mitigations.
Re: (Score:3)
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.
I'm starting to think (Score:2)
Not "just a bit slower" Many times slower! (Score:2)
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
Re: (Score:2)
Do both. Render video on Intel, don't use keys (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Back To The Abacus. (Score:3)
Obsidian and Flint never had these problems. Maybe we SHOULD go back to being Cavemen.
Re:Back To The Abacus. (Score:5, Funny)
There is an immediate fix: (Score:3)
Buy an AMD chip and motherboard.
Re: (Score:2, Insightful)
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.
Re: (Score:1)
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.
Re: (Score:2)
https://www.amd.com/en/corpora... [amd.com]
Re: (Score:2)
I read this part, in the linked original Spectre disclosure, did you?
Google Project Zero (GPZ) Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors.
GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
GPZ Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors.
So, at least two variants of Spectre/Meltdown had to be mitigated on AMD platforms. My point still stands, it's not just an Intel thing, and switching to another processor i
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
DO NOT MAKE FALSE EQUIVOCATIONS PLEASE. (Score:4, Insightful)
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: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
Re:There is an immediate fix: (Score:4, Informative)
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: (Score:1)
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.
Re: (Score:2)
Exactly how would that be muddying the waters? It's fair to point out that issues affecting your system affect your direct competitors, too.
Flawed HW+ inefficient SW = disappointment (Score:3)
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
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
Can security researchers please stop! (Score:1)
Re: (Score:2)
Re: (Score:2)
Some people just do not get it. As if vulnerabilities only exist if somebody is looking.
Re: (Score:2)
Re: (Score:2)
Ah, sorry. There are just too many idiots around that would actually say what you did and be dead serious about it.
Spy vs. Spy (Score:2)
Its like a game to find out what deals the NSA has made with chip makers.
Re: (Score:2)
There's no need for the NSA to have a flaw such as this when you have an entire "Management Engine" on the chip.
Not Itanium (Score:2)
Time to haul out my old Cyrix CPU (Score:2)
Re: (Score:2)