[HN Gopher] Inception: A simple XOR can cause a Microarchitectur...
___________________________________________________________________
Inception: A simple XOR can cause a Microarchitectural Stack
Overflow
Author : ndesaulniers
Score : 74 points
Date : 2023-08-08 16:20 UTC (6 hours ago)
(HTM) web link (comsec.ethz.ch)
(TXT) w3m dump (comsec.ethz.ch)
| FuriouslyAdrift wrote:
| AMD microcode and AGESA updates available on several platofrms...
| time table here: https://www.amd.com/en/resources/product-
| security/bulletin/a...
|
| Expect to see BIOS and OS updates soon if not already out. I
| believ Microsoft has already pushed a cumulative that includes
| some mitigations.
| yomlica8 wrote:
| What does 'not applicable' mean in this context? No problems or
| we don't have plans to fix it? Zen1/1+ doesn't seem present in
| these charts at all.
|
| Edit: It is actually mentioned if you do something clever like
| read.
|
| > No ucode patch or BIOS update, which includes the ucode
| 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.
| lacksconfidence wrote:
| > By reducing all returns in the kernel to a single one, it
| becomes possible to ensure a safe (but still incorrect) branch
| predictor state each time this return is executed
|
| 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?
| nraynaud wrote:
| I think there is already an entire Rube Goldberg machine like
| that in the kernel for spectre mitigation.
| ireallywantthat wrote:
| > Instead of flushing the entire branch predictor state, AMD
| proposed a different mitigation for the Linux kernel. By reducing
| all returns in the kernel to a single one, it becomes possible to
| ensure a safe (but still incorrect) branch predictor state each
| time this return is executed. Keeping previous mitigations in
| mind, this effectively means that AMD opted to have all indirect
| branches forcibly mispredict to a benign location, preventing
| Inception attacks.
|
| So, There will be no decrease in performance or any other
| performance impact if you are running Linux kernel.
| duskwuff wrote:
| As I understand it, there is likely to be a performance
| decrease when executing indirect branches within the kernel.
| mjevans wrote:
| My understanding (which could be incorrect) is that the
| single return location clobbers the branch predictor's leaked
| data with static and (attack) worthless data without
| completely clearing the rest of the prediction cache.
| duskwuff wrote:
| Right, which means the CPU can't effectively predict
| indirect branches (like calls through function pointers, or
| certain types of switch statements).
| Ameo wrote:
| It seems that exploits for this are non-trivial:
| 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
|
| From docs added to the Linux kernel alongside the mitigation for
| this vulnerability:
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
|
| 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.
| dantrujillo wrote:
| Breaking KASLR is also required for the original Spectre attack
| (and Inception can break it by itself). In fact, the threat
| model of Inception is identical to that of original Spectre.
| Inception may be more complicated, but the requirements are the
| same.
| jacquesm wrote:
| Beware when picking your names.
|
| https://www.usenix.org/conference/usenixsecurity18/presentat...
| K0nserv wrote:
| The ~~three~~ two hard problems in computer science: naming
| things, cache invalidation, and off-by-one errors
|
| EDIT: Doh, I can't believe I messed up the joke
| aidenn0 wrote:
| And the three hard problems in distributed queues are:
|
| 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.
| jacquesm wrote:
| That's a nice variation :)
| jacquesm wrote:
| Actually, you didn't mess up the joke, you proved the point
| in a way that not much else could. This is exactly _why_ it
| is a hard problem.
| jacquesm wrote:
| > The three hard problems in computer science: naming things,
| cache invalidation, and off-by-one errors
|
| No, just two.
| mxmilkiib wrote:
| > EDIT: Doh, I can't believe I messed up the joke
|
| Well, it is a hard problem..
| dtx1 wrote:
| Whats the security implication of leaking the root hash?
| K0nserv wrote:
| With the root hash you can crack the root password using tools
| like John The Ripper[0]. More generally, I assume, this exploit
| can be used to read any arbitrary files on the system,
| bypassing regular access control, and plenty of other stuff you
| aren't supposed to be able to do as a non-privileged user.
|
| 0: https://www.openwall.com/john/
| kimixa wrote:
| I'd guess it's not restricted to the /etc/shadow file and could
| leak the contents of "any" memory in the system - that is just
| used as an example that can be (relatively) easily searched for
| in memory due to having a rather unique pattern.
|
| 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.
| K0nserv wrote:
| > 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.
|
| 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.
|
| 0: https://comsec.ethz.ch/research/microarch/retbleed/
|
| 1: https://www.youtube.com/watch?v=dmSPvJxPm80
| e12e wrote:
| > Whats the security implication of leaking the root hash?
|
| 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...).
| thevania wrote:
| when you look properly at the end of the video the root hash
| starts with $y$ implying its yescrypt
|
| 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
| CodesInChaos wrote:
| Rainbow tables are only applicable to unsalted hashes (or
| possibly to ones with tiny salts). They are so rarely
| applicable, that I wouldn't even bother mentioning them.
|
| 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.
| barbito wrote:
| It's just an example. If you can leak kernel Memory you leak
| every process memory. So for example you can leak the content
| of a running browser
___________________________________________________________________
(page generated 2023-08-08 23:01 UTC)