Linux kernel logic allowed Spectre attack on 'major cloud provider' The Spectre vulnerability that has haunted hardware and software makers since 2018 continues to defy efforts to bury it. On Thursday, Eduardo (sirdarckcat) Vela Nava, from Google's product security response team, disclosed a Spectre-related flaw in version 6.2 of the Linux kernel. The bug, designated medium severity, was …
Never...
You are still taking advantage of speculative execution when you run within the same security domain. The problem is when you cross domains. The mitigations prevent you from taking advantage of cross-domain timing variations. Most applications will never bother at any level. The types of application you normally worry about are data processing where data secrecy is paramount (as example, but not limited to, cryptography).
Except--not so much. Retpoline, for instance, has pretty much been built into the entire stack. It doesn't matter if your system is entirely in a single security domain or not--you are going to pay the price for these workarounds unless and until you rebuild your entire system without them. (And that is EXACTLY what you do once your operation is big enough.)
There are SOME kernel workarounds that can be turned off with switches. But I would be shocked if this resulted in differently-compiled code being brought in and not just some branches around the more egregious workarounds.
Remember the original recommendation from the Feds? "Turn speculative execution off". That lasted about twelve hours. It's not that they were wrong--that IS the only way to prevent these attacks in that generation of hardware. It's that the cost was too high. Nothing else.
I have not researched this bit, but the thing is that speculative execution in the presence of caches is going to be fiendishly difficult to accomplish without leaks. And by "fiendish", I mean "there may be some analogue of the CAP theorem or the Heisenberg Uncertainty Principal limiting what can be done".
Quote: "...potential information exposure (e.g., leaked private keys)..."
Some of us are using Diffie/Hellman (first documented in 1976.....yup 1976) to make sure that there are NO PERSISTENT KEYS at all.
Yup...you are reading that right....NO PERSISTENT KEYS at all. Random keys CALCULATED when needed then THROWN AWAY!!!
So.....D/H means no "private keys" at all. It's 2023 today...that would be forty-some years after publication of D/H.
Here at Linux Mansions, we use D/H and safe primes more than 10,000 decimal digits long!
..............Why does this piece in El Reg actually count as news?
From what I understand the Diffie/Hellman protocol works between two entities allowing them to create an encrypted channel between them without private or public keys. But Diffie/Hellman can't be used to verify the identify the entities involved you still need a shared secret or a public/private key infrastructure, or some other means to do that. It is usually just as important to know with certainty who you are talking to as it is to have a secure channel to talk through.
Quote; "...Don't use any encryption method approved by the NSA..."
Reading list:
(1) Applied Cryptography, Steve Schneier
(2) Cryptography Engineering, Ferguson/Scheneir/Kohno
(3) Look up Daniel Bernstein
(4) Look up Diffie/Hellman
(5) Take a look at the gmp library for REALLY big prime numbers
....no need to rely on advice from spooks!!!!
Example:
wtOnwxMbcrQnA3IF2Tqf8hy3sZyrEhgZeNWNudQLEXiFiB2tIPAvQJwJSZcjYTgVgJIvWVGxCTqt
GliFyzUdinARGBwP0D6bCFU1ehIfsdIH4fo1S9wpMxeRcLutu1wBm1e1G5ivCtspcdijKb0RiTUl
S3enMtCdSxW1CrEJqrSF2xa1ubKRMtQnAJYDk5CnIfkxUVO7E1qLs10FezAPGpwJKvKtiBsbMDoZ
c7kpwfoniPcDAXCb6Nuz4fCv6bq5wHErmxaxK32JGPOre5iFAJEP2VUBUZCDaPchMl4H4fQhIfih
WT23uvOZKxgdqZMbkdMN0N6VMPqDglapO7qRS3M9axMj6F6LgBQpuvMv2ji7yRmJAD0L0vwLSz8F
iz4JAPEVSNGVyxit2rYP8LKXIH4XMzWPY1EDUncNcxcXUTiPGNIDszWXqt632Dct2fSVO3QVm1yd
WxC1CpSLIlKRoLUpCLmDQxWb8BMNyhUdWhQdE1s9Qli3gZ4n69Cbg3WDwda3adYTSzO3YBerIDon
0ZYLONSxyFgtgrsFGVk58RGf81kX6Foz4jUhWNmjgVGBSFwvwxcXyjo5MNYR6Vk7mvmnSNIBQvOd
UdQVwHav6rqzwZMpk5k9ijO3GzYNE5ejivMlqxGFgL4vkJSNIz6TGnoFkRcfWnSBgpudglMtGToJ
q9uhO9ET0ZSTQV6ng9KTIrIl
Sorry....but this is multiply encrypted using a VERY unfashionable book cipher.....no...not AES...not IDEA.....not Blowfish.....not samba20....
Guess the book!! Guess the algorithm for words NOT IN THE BOOK!! ...and then there's spelling mistakes!!!
Yup..........plenty of opportunities for algorithms not "approved by the NSA"........................
Take more of the dried frog pills, AC.
The Spectre based attacks are inherent in the design of speculative execution, and non trivial to architect against. Intel and AMD aren't affected in quite the same way, as their architectures are different.
You could of course take the OpenBSD approach, and disable hyperthreading by default, after they looked at it and found too many edge cases where things might go wrong.
@BinkyTheMagicPaperclip
Confused here.....messaging is encrypted (you know....AES, samba20 and so on...maybe a book cipher!).....
Messaging is intercepted either in transit....or actually on an actual machine.
Even if the actual machine is compromised by Spectre......does that have ANYTHING AT ALL to do with a compromise to the encryption?
P.S. Where might you (yup..you!) get these dried frog pills?
I hear a lot about speculative execution vulnerabilities, how hard they are to mitigate, and how they can potentially be exploited to nefarious ends, but much less about actual attacks against "major cloud providers" or other infrastructure using these vulnerabilities. Either I'm being terribly ignorant, or it feels as if we're chasing an actual spectre, not a practical issue with real-life repercussions.
The issue with your comment is that if people are actively using it, they're unlikely to shout it from the roof-tops, and if you are a victim, the first you will hear of it is long after the leaked information is used to compromise any systems, making it extremely difficult to identify what the vector for the loss was, and that is even if they know they've been a victim at all.
I agree, some of these vulnerabilities are actually difficult to exploit, and more often than not probably return some completely uninteresting data most of the time, but that's not an excuse to not take every preventative measure available.
My problem is that these preventive measures cost a lot, not just in terms of time and money to implement, but also in terms of performance. Slowdowns of up to 70% percent and other horrifying numbers are thrown around - if that is the price we have to pay to be protected from a certain threat, it'd be nice if it were a threat that is provably dangerous and exploitable, and by "provably" I mean outside of academic papers.
You don't have to tell me about this problem. It takes months to arrange an out-of-band service shutdown on the systems I look after, even for left-leg right-leg maintenance. Fortunately, they are Power AIX systems which seem a little less affected by Spectre type problems (although IBM have issued both firmware and OS fixes, mainly as a PR exercise IMHO), and these systems are also less likely to be targeted by miscreants because of architectural differences, and are also some way back from the places people can get to from the Internet.
One of the problems of the initial Meltdown vulnerability was that in both Windows and Linux on X86_64 systems, the kernel memory was mapped in to the address space of a process (although it was rendered inaccessible by protection bits, which is what Meltdown worked around). AIX never had this problem (kernel is in a separate virtual address space from processes, with only a small part of the kernel text segment containing the system call vectors and 'fast' system call code mapped into a process address space), so Meltdown was never a problem with AIX. I think this is also mainly true for may of the other speculative execution problems that affect Intel.
First, even after this class of vulnerability was revealed, it was quite difficult to pull off in practice. Then, the mitigations were put in place. While I am very much on record as explaining that this class of vulnerability cannot be mitigated entirely in software, that does not mean that things like retpoline don't make it more difficult to execute.
But you don't wait for an actual exploit to be active in the wild to address it. In particular, if there WERE some massive exploit out there, it would directly affect AWS's bottom line in a big way. So, they care a lot about doing what can be done--BEFORE there is an actual dam break.
This is the usual pushback I get from developers who don't want to implement security: prove this bad practice (process separation, address isolation, unsalted hash, buffer overrun, double frees, integer overflow, etc.) can be hacked easily and show me the hack. Security is built in layers with the principle of zero trust applied liberally. Each and every component must do its security properly.
The goal is not have obvious flaws which can be exploited.
AWS itself probably protects its own secrets in a completely separate CPU+memory (simplifying it a bit here) but many companies run their VMSs/ (EC2s/K8s pods, lambdas) with all kinds of secrets and PII.
One can imagine a nation-state just deploying 1000's of EC2s and K8s pods scraping data for years, mining the data, and then giving it to their state-sponsored hackers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
