6 ms·
Inception: A simple XOR can cause a Microarchitectural Stack Overflow
- jacquesm 3y agoBeware when picking your names. https://www.usenix.org/conference/usenixsecurity18/presentation/corteggiani https://www.usenix.org/conference/usenixsecurity18/presentat...
- K0nserv 3y agoThe ~~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
- mxmilkiib 3y ago> EDIT: Doh, I can't believe I messed up the joke Well, it is a hard problem..
- jacquesm 3y ago> The three hard problems in computer science: naming things, cache invalidation, and off-by-one errors No, just two.
- aidenn0 3y agoAnd 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 3y agoActually, 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.
- deepserket 3y agoThere are only two hard problems in computer science: Cache invalidation ParaOff-by-one llelism errors
- dtx1 3y agoWhats the security implication of leaking the root hash?
- K0nserv 3y agoWith 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/ https://www.openwall.com/john/
- rsaxvc 3y agoIt seems like this would only allow reading memory resident for some other reason. Still bad, but I do not think it would allow directly reading files that weren't already in memory. As for /etc/shadow, it would be loaded any time someone attempts to login, and might even stick around in the page cache...
- kimixa 3y agoI'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 3y ago> 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/ https://comsec.ethz.ch/research/microarch/retbleed/ 1: https://www.youtube.com/watch?v=dmSPvJxPm80 https://www.youtube.com/watch?v=dmSPvJxPm80
- FuriouslyAdrift 3y agoAMD microcode and AGESA updates available on several platofrms... time table here: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html 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 3y agoWhat 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 µ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.
- tetumetal 3y agoThe original video from the authors of inception runs on a zen4. But, the authors also claim that zen2 is vulnerable to the exploit. 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/inception/zen_1_2 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.
- ireallywantthat 3y ago> 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 3y agoAs I understand it, there is likely to be a performance decrease when executing indirect branches within the kernel.
- mjevans 3y agoMy 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 3y agoRight, which means the CPU can't effectively predict indirect branches (like calls through function pointers, or certain types of switch statements).
- lacksconfidence 3y ago> 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 3y agoI think there is already an entire Rube Goldberg machine like that in the kernel for spectre mitigation.
- Ameo 3y agoIt 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/linux.git/commit/?id=138bcddb86d8a4f842e4ed6f0585abc9b1a764ff 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 3y agoBreaking 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.
- cryptonector 3y agoThis is a bad week for speculative execution.
- nine_k 3y agoI suspect that in a decade or two we will see speculative execution as we see shared mutable state today: a dangerous trap that should be best avoided in any new designs.
- colinsane 3y agoisn’t every attack based on speculative execution actually just an attack over shared mutable state? i.e., if the branch predictions, cache, and so on weren’t both shared and mutable, speculative execution wouldn’t be so problematic?
- nine_k 3y agoIndeed. Not just shared, but shared across security domains, e.g. across OS processes, or across the kernel / userspace boundary. 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.
- pdw 3y agoOr the mistake is that we're running different trust domains on the same CPU core. 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.
- bpye 3y agoThere is state shared between cores too though, at the very least L3, probably IOMMUs, etc. I wouldn’t be entirely surprised if there are issues we haven’t found that exist there.
- carlintveld 3y agoIs it possible to break out of a virtual machine and gain access to the hypervisor with this?