SoylentNews is people
SoylentNews
Meet TLBleed: A crypto-key-leaking CPU attack that Intel reckons we shouldn't worry about
Intel has, for now, no plans to specifically address a side-channel vulnerability in its processors that can be potentially exploited by malware to extract encryption keys and other sensitive info from applications.
A team of researchers at the Systems and Network Security Group at Vrije Universiteit Amsterdam, in the Netherlands, say they were able to leverage the security weakness to extract crypto keys from another running program in 99.8 [percent] of tests on an Intel Skylake Core i7-6700K desktop CPU; 98.2 percent of tests on an Intel Broadwell Xeon E5-2620 v4 server CPU; and 99.8 per cent of tests on a Coffeelake part.
Their code was able to lift a secret 256-bit key, used to cryptographically sign data, from another program while it performed a signing operation with libgcrypt's Curve 25519 EdDSA implementation. It took roughly 17 seconds to determine each of the keys using machine-learning software and some brute force, according to a paper detailing the attack, seen by The Register this week.
[...] The extraction technique is not reliant on speculative execution, and thus is unrelated to Spectre and Meltdown. Instead, it builds upon the exploitation of Intel's Hyper-Threading technology and the processor caches to leak data, which is a known security problem with its own mitigations.
[...] [Ben] Gras also believes AMD's hardware threading technology in its latest Zen processors – Ryzen, Threadripper, and Epyc – are at risk from TLBleed, as the CPU cores can also each run multiple threads simultaneously just like Intel parts. A spokesperson for AMD had no comment.
(Score: 2) by Azuma Hazuki on Sunday June 24 2018, @01:53AM (9 children)
A few days ago on Phoronix I saw a story saying OpenBSD disables HyperThreading by default on Intel CPUs. This sounded oddly drastic to me, and the reason they gave--something about different security domains on the same pair of hyperthreads--didn't pass the smell test. This does. Makes you wonder if we're going to need to go backwards in terms of chip design to mitigate these things...
I am "that girl" your mother warned you about...
(Score: 2, Interesting) by Anonymous Coward on Sunday June 24 2018, @02:32AM
The OS could perform some level of mitigation by making sure all threads running on a given CPU are from the same App/security domain.
(Score: 4, Funny) by takyon on Sunday June 24 2018, @02:34AM (1 child)
1. Disable branch prediction to prevent speculative execution attacks.
2. Disable hyperthreading to prevent side-channel vulnerability.
3. Disable multicore to prevent side-channel vulnerability.
4. Turn off the computer to prevent secret networking.
5. Unplug the computer to prevent secret "always-on" networking.
6. Chuck the computer into a volcano to prevent secret battery-powered "always-on" networking.
Your system is now secure!
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 2) by RS3 on Sunday June 24 2018, @03:08AM
You've inspired me: in my spare time I will design CPU adapters to allow original Pentiums to replace newer flawed CPUs.
(Score: 2) by RS3 on Sunday June 24 2018, @02:50AM (3 children)
Yeah, but how far back? I'm sort of half paying attention to all of this CPU mess, and from what I think I understand most of it goes back to the Pentium Pro? And cache RAM? And now to speculate a bit, the cache controller pre-fetches stuff from RAM that might not belong to a particular running thread, but you can read ahead and get something you don't own? So somehow the memory range ownership logic doesn't properly talk to the cache controller, if at all? If I'm on track so far, then no microcode can fix missing wires and gates, but Intel could surely disable speculative execution, cache pre-fetches, etc., in microcode, and I think they should be forced to do so. And give everyone vouchers for new CPUs, or big discounts at least.
So this flaw has existed for almost 25 years, and we're just now seeing / hearing about exploits? Maybe someone knew about it many years ago?
(Score: 0) by Anonymous Coward on Sunday June 24 2018, @03:25AM
Pretend you are satoshi nakamoto, or whatever where it actually matters. You just have to assume all privacy/security on the internet is elaborate snake oil.
(Score: 1, Interesting) by Anonymous Coward on Sunday June 24 2018, @03:44AM
Explains why curve 25519 was all the rage with NIST.
That's odd. My tinfoil's not even on. Our taxes paying to discover processor flaws, then keeping them classified so as to be used against us. Also some taxes to pay Intel and AMD to have exceptional difficulties finding such flaws so they keep baking them in.
(Score: 1, Informative) by Anonymous Coward on Sunday June 24 2018, @02:10PM
Intel introduced hyperthreading 15 and a half years ago, in November 2002. (source [archive.org])
(Score: 3, Informative) by takyon on Sunday June 24 2018, @05:02AM
This story linked the two: https://www.theregister.co.uk/2018/06/20/openbsd_disables_intels_hyperthreading/ [theregister.co.uk]
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 2) by HiThere on Sunday June 24 2018, @05:41PM
To me hyperthreading has always seemed like the wrong approach. The correct approach is simpler processors and more of them. That wouldn't necessarily make them immune to various attacks, but with enough processors the OS could pick a couple to run "secure tasks" and limit access to them. For my purposes the best way for the processors to communicate would be by message passing, where the messages aren't code, but basically strings of integers that the processor interprets according the the program running in it. Think pre-html email. Attachments are embedded ala uuencode.
This approach would not, of course, prevent attacks, but it would enable them to be encysted.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.