Slashdot Mirror
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.
Here we go again! I'm going to go make more popcorn.
As opposed to spammy, pop-up filled ZDNet article.
https://www.theregister.co.uk/...
The first principle is that you must not fool yourself - and you are the easiest person to fool. -Richard Feynman
Intel's committment to backward compatiblity
Sig Follows: "Suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself." -- Mark Twain
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.
"First they came for the slanderers and i said nothing."
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?
Some drink at the fountain of knowledge. Others just gargle.
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.
Obsidian and Flint never had these problems. Maybe we SHOULD go back to being Cavemen.
Buy an AMD chip and motherboard.
Anons need not reply. Questions end with a question mark.
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.
Instead of issuing a CVE they should be issuing a "spoiler alert".
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 effect that meaningful secrets will take years to leak.
Ian Ameline
"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.
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.
Socialism: a lie told by totalitarians and believed by fools.
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Some people just do not get it. As if vulnerabilities only exist if somebody is looking.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Interesting how this much-maligned, and all but dead, processor architecture remains immune to these attacks.
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
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 execution or any of that fancy stuff. A Core i9 has billions of transistors. Lots and lots of places for things to leak. Some of the smaller, much simpler CPUs have a few thousand transistors. That's a lot less attack surface. No reason not to have both. The DS5250 is designed for security and it costs about a buck.
bonus points if you remember these
Possibly, but so far, Intel HAS shown more flaws, more serious flaws, and a bigger performance hit from the mitigations.
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 isn't going to protect you from all variations of future attacks, just against a handful of intel specific ones that we know about right now. These are flaws inherent to our current processor designs and will probably take a few generations of processors to make secure.
it was not obvious that I was JOKING?!? :-/
Guessing it's because they hold many Defence and NSA contracts. Too big to fail.
Ah, sorry. There are just too many idiots around that would actually say what you did and be dead serious about it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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 have to get new product out to the marketplace that makes corporate desktop
fleets stop choking on whatever abomination of an application suite firms like PeopleSoft
are making them run.
In general, the problem comes from really smart people designing chips to run spaghetti code
very fast, instead of just optimizing code, because designing chips payed better, because
the people who were paying coders just wanted it to work and were not capable of discerning
good product from bad as long as the payroll went out on time and everyone got their cat pics
posted.
Someone had to do it.