Inception: A simple XOR can cause a Microarchitectural Stack Overflow
comsec.ethz.ch
comsec.ethz.ch
In order to exploit vulnerability, an attacker needs to:
- gain local access on the machine
- break kASLR
- find gadgets in the running kernel in order to use them in the exploit
- potentially create and pin an additional workload on the sibling
thread, depending on the microarchitecture (not necessary on fam 0x19)
- run the exploit
That fact that breaking kASLR is required for this and the considerably complex exploit chain compared to others makes me worry about this a lot less compared to the exploitable-from-JS ones.
I'll wait for some benchmarks to come out from Phoronix or similar and depending on how bad the perf hit is, I will consider disabling mitigations for this on my personal computer.
If someone has gotten a malicious binary running on my machine - even without root permissions - it's already over anyway.
Expect to see BIOS and OS updates soon if not already out. I believ Microsoft has already pushed a cumulative that includes some mitigations.
Edit: It is actually mentioned if you do something clever like read.
> No µcode patch or BIOS update, which includes the µcode patch, is necessary for products based on “Zen” or “Zen 2” CPU architectures because these architectures are already designed to flush branch type predictions from the branch predictor.
However, in zen2, KASLR cannot be broken by inception, in a reasonable time. So, the authors proposed to install a kernel module to get the kernel address. Then, pass this address to the exploit: https://github.com/comsec-group/inception/tree/master/incept...
From the practical point of view, it does not make sense to require the installation of a kernel module to get some information needed by the exploit. It's kind of a cheat. If I can install a kernel module, it means that I already have root access.
So, in my opinion, from the practical point of view KASLR is enough to mitigate inception in zen1,2. The authors claim that this architectures can be exploited it's an overstatement.
I'm way out of my depth here, what does this mean? My naive guess is that they ensure there is a single assembly instruction in the entire kernel that can do a return, and every place that wants to return jumps to that return?
So, There will be no decrease in performance or any other performance impact if you are running Linux kernel.
https://www.usenix.org/conference/usenixsecurity18/presentat...
EDIT: Doh, I can't believe I messed up the joke
No, just two.
Well, it is a hard problem..
2. In-order delivery
1. Once-only delivery
1. Once-only delivery
If someone notes that's only two problems, you can add that reliable delivery is the third.
Cache invalidation
ParaOff-by-one
llelism errors
As for /etc/shadow, it would be loaded any time someone attempts to login, and might even stick around in the page cache...
I'm a little confused about the presentation of this - I think a fair bit of work has been put into the presentation and make it look "hacker" rather than actually required for the exploit, which doesn't fill me with confidence, but I guess we'll see when the actual description gets released.
Like why is the shell loop re-building the exploit code? The output seems strangely character rate-limited but extremely even when if it was being rate-limited by the exploit itself I'd expect more noise if it relies on some probability to read the memory contents, and absolutely no description of the technique itself.
> Like why is the shell loop re-building the exploit code? The output seems strangely character rate-limited but extremely even when if it was being rate-limited by the exploit itself I'd expect more noise if it relies on some probability to read the memory contents, and absolutely no description of the technique itself.
This team has done stuff like this before, they were behind Retbleed[0], for which they released a similar style video[1], last year. I expect more details will follow after the USENIX Security Symposium.
more info here https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en...
https://www.openwall.com/yescrypt/
once you have the hash you have to use some rainbow tables if they exist for that hash function or bruteforce it
the authors of yescrypt claim: "Technically, yescrypt is the most scalable password hashing scheme so far, providing near-optimal security from offline password cracking across the whole range from kilobytes to terabytes and beyond. "
in any way, this is a local attack, someone / some software on your local machine would need to execute it so i am not overly stressed, password hashes leak all the time from all different sources
yet, it does worry me because my AMD stock is dropping on value because of this today :D
On that list, NT is the only completely unsalted hash, plus DEScrypt and its variants might still be susceptible with its 12 bit salt. Like all decent password hashes, yescrypt is salted.
That you can try to crack the hash off-line with something like hashcat.
For a random, salted, 22 character password (roughly log2(62^22)~130 bits of entropy, no rainbow tables because of the salt) - it might not be game over.
On the other hand - if you can make an educated guess at the password - it's now trivial to check a few million variations without having to try to log in.
As other's mentioned - reading arbitrary memory is probably worse (eg keyboard buffer, getting the plaintext password if a user logs in...).
Speculating within one security domain would not be problematic, because anything such speculation allows to glean is already accessible normally. This is sort of similar to having a single reference to a mutable object, which is also safe.
All the various mitigations have already been very costly (something like a performance loss of 10% on current-gen CPUs?). Getting rid of speculative execution entirely would cost far, far more.
It's very hard to not make that mistake. Think of all the websites running in your browser on your laptop. Isolating all those trust domains is going to be quite costly.