3 ms·

> I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical. You'll be looking for a needle in a haystack. Do you seriously tru

> I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical. You'll be looking for a needle in a haystack. Do you seriously trust it to be like looking for a needle in a haystack? That haystack becomes much much smaller if you know where to look. An excellent adversary would know a lot about kernel memory and what data to get. Grab a few bytes for a pointer... grab a few more bytes for another pointer offset from the first... just a few pointers and now you're at the secret storage arena. A few hundred bytes/sec is just a few hundred bytes/sec away from gaining sensitive information.

icedchai 4y ago
If you can directly de-reference kernel memory, sure. If you have that capability, why do you need this exploit? I'm still skeptical.
- 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 ago
    Suppose 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 ago
      It'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.
userbinator 4y ago
That assumes you have direct control over which addresses you can read, which is far from true in the scenario of most concern (JS running in the browser). It is at best like listening to the conversation of some people walking by, with a ton of background noise, and hoping you'll hear enough to make sense of it.

icedchai 4y ago

If you can directly de-reference kernel memory, sure. If you have that capability, why do you need this exploit? I'm still skeptical.

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 ago
  Suppose 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 ago
    It'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.

userbinator 4y ago

That assumes you have direct control over which addresses you can read, which is far from true in the scenario of most concern (JS running in the browser). It is at best like listening to the conversation of some people walking by, with a ton of background noise, and hoping you'll hear enough to make sense of it.