BlindSide: Intel/AMD Speculation Bugs Under Microscope Again
Researchers have published frightening details on what they’re calling BlindSide. It’s a way of defeating the Address Space Layout Randomization (ASLR) in kernels such as Linux.
So what? So if bad actors get a toehold into a minor kernel bug, they can pwn the whole shebang in minutes. They do it by co-opting our old friend speculative execution.
And do it without being detected. Yikes. In today’s SB Blogwatch, we look closely at how it works.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Bot Battle Beats.
Sky Falling—Film at 11
What’s the craic? Michael Larabel briefly reports—“Security Researchers Detail New “BlindSide” Speculative Execution Attack”:
Security researchers … have publicly detailed “BlindSide” … a new speculative execution attack vector for both Intel and AMD processors.
…
From a single buffer overflow in the kernel, researchers claim three BlindSide exploits in being able to break [ASLR], break arbitrary randomization schemes, and even break fine-grained randomization. The researchers were looking at Skylake/Whiskeylake through Coffee Lake plus AMD Zen+ / Zen 2 processors in their research.
Come again? Catalin Cimpanu says the “technique abuses the CPU’s internal performance-boosting feature to bypass OS security protection”:
Memory addresses are important for an attacker. If an attacker knows where an app executes its code inside the memory, a hacker can fine-tune exploits that attack particular applications and steal sensitive information.
…
ASLR works by randomizing the location where code executes inside memory, effectively neutralizing attacks. … To bypass ASLR, an attacker typically needs to find an “information leak” type of vulnerability that leaks memory locations; or the attacker can probe the memory until they find the proper location.
…
Both techniques are hard to pull off … especially the second, which often leads to system crashes. [BlindSide] works by moving this probing behavior into the realm of speculative execution … repeatedly probing the memory until the attacker bypasses ASLR.
Since this attack takes place inside the realm of speculative execution … failed probes and crashes [are invisible] as they [are] discarded. [The] attacks also work despite the recent mitigations that CPU vendors have added against speculative execution attacks like Spectre.
Who are these researchers? Step forward Enes Göktaş, Kaveh Razavi, Georgios Portokalidis, Herbert Bos and Cristiano Giuffrida—“Hacking Blind in the Spectre Era”:
Using speculative execution for crash suppression allows the elevation of basic memory write vulnerabilities into powerful speculative probing primitives that leak through microarchitectural side effects. … To showcase speculative probing, we target the Linux kernel, a crash-sensitive victim that has so far been out of reach of blind attacks.
…
The key idea of using a software vulnerability instead of indirect branch poisoning or injection also allows attackers to bypass all the deployed mitigations against speculative execution attacks. Moreover … speculative probing cannot be detected by existing BROP-style defenses such as anomalous crash detection and booby trapping.
…
We demonstrate BlindSide attacks by means of a real-world buffer overflow vulnerability … in a number of end-to-end kernel exploits, which implement speculative probing, collectively bypass a variety of randomization solutions (including the recent FGKASLR) as well as version entropy. [We] ultimately obtain full-system compromise.
…
We also consider possible defenses. [But] the mitigation of BlindSide attacks is difficult.
Got root? In case you didn’t watch the video, yes they did. DigiShaman quips, “It’s broken Jim”:
So, does disabling [hyperthreading] all together help? Or will this require a whole new CPU. What a ****ing mess!
But it’s just another zero-day, thinks Spam:
Is this attack even plausible? Seems it is dependent on other faults first?
So just fix the kernel bug? NOT SO FAST, shouts COMPUTER1313: [You’re fired—Ed.]
[The initial exploit] works only against Linux systems that have not been updated to 5.9 (which I would not be surprised if there are many, many outdated systems running). But all it would take is to find another buffer overflow bug to use the exploit chain.
At which thegarbz sarcastically snarks up a storm:
You should propose that to Intel. They can come up with a fancy name for it, something that reflects how it’s hardened against attacks. Like titanium. Except Intel.
…
I know: Itanium! I’m sure a system which requires a paradigm shift in compilers will sell well.
Speculation considered harmful in general. But xfcemint wouldn’t mourn its passing:
For a modern CPU, only OOO (out-of-order) is important, speculation is just a nice extra. … OOO does not require speculation. OOO is perfectly safe, at least as far as we currently know.
…
Also, speculation is safe if done just on registers and a few buffers close to the ALU. The problem with current CPUs is that manufacturers are relentlessly and dangerously speculating on every **** they can think of [just so] the CPU looks good on benchmarks.
Meanwhile, Antique Geekmeister artfully quotes Donald Knuth:
”Premature optimization is the root of all evil,” … and this is an example of an “optimization” that has bred an entire industry of time wasted by trying to mitigate the resulting dangers and errors.
And Finally:
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Fritzchens Fritz (public domain)
