Software alone can’t save us from Spectre-class vulnerabilities in modern CPUs. That’s the scary conclusion from a bone-dry research paper penned by Google engineers.
Be afraid. Be very afraid. Because there’s no evidence that CPU vendors are actually taking this thing seriously—even though they’ve known about it since June 2017 (perhaps even longer than that).
So all we have are code fixes that slow down our infrastructure without fixing the underlying problem. In this week’s Security Blogwatch, we run for the hills.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: more 1980s craziness.
Scary wakeup call
What’s the craic? Thomas Claburn burns Spectre chip flaws can't be killed by software alone:
Security researchers have analyzed the impact of the data-leaking Spectre vulnerabilities afflicting today's processor cores. [They] show that they can … exploit the … speculative-execution flaws … allowing attacker-supplied code … to read all memory in the same address space.
…
There are already some mitigations in place in browsers … limiting what any malicious JavaScript can spy on. … However, the underlying threat is still there for … other applications interpreting attacker-supplied code.
…
[Software] safeguards within a process can't stop Spectre; you have to go down to hardware-based separation. [So] if you're developing software that interprets external code – such [as] a cloud-based execution environment … this is something to be very much aware of.
…
Spectre, as its name suggests, involves the exploitation of speculative execution. … The ability to peer into the future can be abused. … The basic problem is that chip designers traded security for speed.
…
Software … fixes like microcode updates and techniques like Retpoline … appears to be futile. … They slow things down without truly fixing the problem.
…
Help has to come from hardware, too, in the form of better process isolation.
Ouch. Lucian Armasu concludes Side-Channel Attacks Inescapable Unless CPU Designs Change:
Spectre speculative execution attacks are here to stay without serious changes to the design of modern CPU architectures. … The team of security researchers … work on Google Chrome’s V8 JavaScript engine.
…
According to the research report, to truly fix all existing as well as future Spectre bugs, the CPU makers need to come up with new CPU microarchitecture designs. … So far, Intel has only made promises about including some hardware fixes for known and specific Spectre bugs.
…
As part of its defensive work for the V8 JavaScript engine, the team … tried to develop various software mitigations. … However, they noted that none of these solutions are comprehensive enough and come with serious performance penalties. … The researchers believe that hardware and OS process isolation is now needed more than ever.
Messers Mcilroy, Sevcik, Tebbi, Titzer, and Verwaest speculate to accumulate: [You’re fired—Ed.]
This paper explores speculative side-channel attacks and their implications for programming languages. These attacks leak information through micro-architectural side-channels, which we show are not mere bugs, but in fact lie at the foundation of optimization.
…
These vulnerabilities present formidable challenges for effective, efficient mitigation. … We now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations.
…
Spectre defeats an important layer of software security. … Untrusted code can … read all memory in the same address space through side-channels.
…
Hardware/OS process isolation is needed now more than ever. … It has become painfully obvious to us that we are facing three massive open problems:We’ve been extraordinarily successful at making [CPUs] faster and more powerful, but also more complicated, facilitated by our many ways of creating abstractions. The tower of abstractions … leak, side-channels exist outside of our models, and now, down deep in the hardware … there are vulnerabilities in the very chips we deployed the world over.
- Finding µ-architectural side channels requires enumerating and modeling relevant µ-state, a difficult task for processors that are closed source. …
- Understanding vulnerabilities … requires us to understand complex µ-state in black-box processors.
- Mitigating vulnerabilities is perhaps the most challenging of all. …
…
Our mental models, are wrong; we have been trading security for performance and complexity all along and didn’t know it. … Spectre is perhaps, too appropriately named, as it seems destined to haunt us for a long time.
What we need right now is a real-world analogy. Here’s Zenst:
In fairness … CPU design is more complex than writing tax laws. Yet we have exploits for tax laws appearing and used all the time by large corporations. Whilst the comparison is not ideal and some would say, unfair. It does highlight that nothing is perfect and what we may class as perfect today (or darn close), could and may very well be classed as Swiss cheese in the future.
…
After all, if CPU cores had isolated caches instead of sharing, then that would mitigate so many issues, yet it would cost more to make and most consumers would not appreciate the extra cost for what to them is little value in return above and beyond the cheaper solution. That's business for you and CPU's are made by them for profit.
Isolated caches? Dr Spin zones out:
Essentially, the risk is due to speculation or otherwise in one thread impacting … another. … If you allow a thread to use data that is in the cache because another thread put it there, then you are on the slippery slope to hell – even if you are destined to get there quicker, this might not be a good plan! Threads need to be wholly and completely isolated.
…
(Asking strangers to hold your wallet doesn't necessarily work out well either).
So phkahler offers a radical solution:
We'll need to have non-speculative execution for cloud CPUs and stronger efforts to keep untrusted code off our high performance CPUs. This may even lead to chips with performance cores and trusted cores … i.e., ones that don't implement speculative execution or share cache with other cores. Untrusted code needs to be run in physical isolation, not just virtual isolation.
…
But the real solution to all of this is not to run untrusted code at all. … The simplest and most obvious thing we need to do is disable JavaScript. I mean how can you possibly trust code that came in a 3rd party payload used for advertising? How can you trust anything from Facebook? Or any of them? The answer is that you can't and in may cases should not.
…
What I think is necessary is for people to stop running code from random places. … Google could work without running stuff on my machine.
Yeah, like that’s ever going to happen. Azuma Hazuki claims to be “that girl” your mother warned you about:
Something I'd been wondering since this came out: isn't the solution not to drop speculative execution entirely, but just to make sure parts of the chip can't read what they have no business reading? … As no network is secure without a firewall, access controls, and ideally some sort of IDS, maybe CPUs need to be designed this way too.
So we need a return to wideword designs, like Itanium? zaarn_ thinks so:
VLIW-family CPUs like the Mill or Microsoft's EPIC experiment could eliminate the problem. … Compiler-based speculation has some advantages, notably that the only information it leaks is information from the system it was compiled on. The actual hardware that it runs on doesn't leak.
The Mill CPU Designers did give a very good talk on why exactly the CPU is immune to most side-channel attacks based on speculative execution. They even make sure the cache doesn't leak any information because it can roll back cache hits from branches and reload data evicted during a branch.
Meanwhile, a super-cynical Whoever snarks up a storm:
In other news … Google has a special deal on single tenant nodes.
The moral of the story?
Don’t get complacent: These mitigating kernel patches and microcode aren’t going to save you.
And finally
If today’s streaming companies were around in the 1980s
You have been reading Security 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 sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.
Image source: Dion “smashmirrorcardboardface” Jones (cc:by-nd)
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
