3 ms·
Haha, speaking of Linus’s carefree attitude towards leaving dangerous things unattended because they are not imminently threatening”, this is an opportune momen
by paulmd 4y ago
Haha, speaking of Linus’s carefree attitude towards leaving dangerous things unattended because they are not imminently threatening”, this is an opportune moment to point out that AMD has a series of unpatched vulnerabilities (Take-A-Way and PREFETCH, both by Moritz Lipp of Spectre/Meltdown fame) that leak kernel page table mappings as well, unless you enable KPTI, which AMD continues to push as off-by-default due to performance impact.
So on an AMD system you indeed know exactly where to look to get into kernel memory. The processor will just tell you where to look.
- userbinator 4y agoSuppose you know that data of interest is at address X. Now how do you propose actually reading that specific address from e.g. JS running in a browser? IMHO having that much knowledge of the system you're attacking means you're not likely to need the side-channel anyway.
- Sirened 4y agoIt's just like traditional kernel exploitation. Say you have a classic relative kernel read due to an out of bounds read from a heap object. How do you read secrets that way? Well, you leak the ASLR slide, find a relevant global, and start pointer chasing until you reach the object you want. Doing this with speculative reads is just the same as with a regular kernel bug except that now it's slow. Like, legitimately, there are some off the shelf kernel exploitation kits that let you swap in an implementation for read functions and then they'll work straight away whether or not the read is coming from speculative means or a classic bug.