If you've done exploitation before, you'll probably recognise this as being similar to a ROP gadget. We're looking for a sequence of code in kernel space that happens to have the right sequence of instructions to leak information via cache.
-
Show this thread
-
Keep in mind that the execution is speculative only - the processor will later realise that I didn't have the privilege to jump to that code and throw an exception. So the target code has to leak kernel data via cache side-channels like before.
1 reply 13 retweets 100 likesShow this thread -
You'll also notice that we need to know address of the target kernel code. With KASLR this isn't so easy. Project Zero's writeup explains how KASLR can be defeated using branch prediction and caching as side-channels, so I won't go into the details here. https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html …
1 reply 18 retweets 113 likesShow this thread -
What makes this extra powerful is that it works across VM boundaries too. Instead of a traditional indirect jump (e.g. jmp eax), we can use the vmcall instruction to speculatively execute code within the VM host's kernel in the same way we would our VM's kernel.
1 reply 20 retweets 113 likesShow this thread -
Finally, there's the third approach. This involves a flush+reload cache attack against kernel memory, similar to the first variant of the attack but without requiring kernel code execution - it can all be done from usermode.
1 reply 14 retweets 94 likesShow this thread -
The idea is that we try to read kernelspace memory using a mov instruction, then perform a secondary memory read with an address based on the value that was read. If you're thinking the first mov will fail because we're in usermode and can't read kernel addresses, you're right.
1 reply 13 retweets 90 likesShow this thread -
The trick is that the microarchitectural implementation of mov contains the memory page privilege level check, which itself is a branch instruction. The processor may speculatively execute that branch like any other.
2 replies 14 retweets 99 likesShow this thread -
So, if you can outrun the interrupt, you can speculatively execute some other instruction that loads data into cache based on the value read from kernelspace. This then becomes a cache attack like the previous tricks.
1 reply 15 retweets 104 likesShow this thread -
And that's just about it. For full details I recommend checking out the two papers, as well as the Project Zero writeup I linked above. https://spectreattack.com/spectre.pdf https://meltdownattack.com/meltdown.pdf
7 replies 55 retweets 253 likesShow this thread -
(this thread was never intended to be quite so long...)
32 replies 16 retweets 362 likesShow this thread
Thanks heaps for the write-up!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.