High-value zero days like what you're describing would not get wasted on stealing bank information from random working schlubs like us.
I think it is a reasonable approach to personal information security to focus on ensuring that you are robust to families of exploits which have concrete proof of concept in practice, and not wasting calories worrying about stuff that is (for the time being) mostly theoretical.
This advice obviously does not apply if you are protecting valuable corporate IP, or a repository of personal information, or god forbid national security secrets.
Oh, definitely - it wouldn't be used for trivial things like that, at least not for quite a while.
[Edit: hopefully having better mitigations in hardware by then]
My comment didn't follow the thread particularly well, I wasn't so much worried about the everyday person - just that this could be weaponized [against someone/thing]
My worry about this really goes as far as... keep the mitigations enabled. That's it.
A lot of people disable them today because they're aren't dangerous today - if nothing else, offering a countering opinion to change that trend.
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. There are easier, faster attacks available. I won't lose sleep over it.
>I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical.
Not at all - you don't sequentially dump all of kernel space - you probabilistically sample it and make guesses of where to look next based on the fingerprints you already have seen. It takes not long at all to find useful stuff.
Find a block that matches a known library? Ok, that entire section is known. Find a page table? Golden - you quickly walk it and you now know how everything else is laid out. Find any of zillions of known structures? Now you can walk those nicely.
I've written code to do kernel reconstruction over the PCI bus from an external security monitor - it's not hard or slow to reconstruct all of memory efficiently and without having to sample much simply by using tricks like these.
It's just like playing Battleship, except you can do it much more accurately with perfect knowledge of probabilities.
Having access to a PCI bus is a bit different than what we're talking about here. Explain to me how are you going to "quickly" walk a page table or other known data structure if you don't have direct control over what you can read?
Their paper states "RETBLEED can leak arbitrary kernel data from an unprivileged process with all the mitigations up on various Intel and AMD systems." They control the branch target buffer so can point to whatever they want.
> 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.
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.
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.
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.
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.
I won't either to be honest. These are certainly of the 'stars must align' category [today], I just find them interesting.
The speed comes down to time, again - either more efficient methods could be developed (perhaps in combination with other seemingly not-of-interest vulns) or simply by hardware getting even faster.
It also assumes an attacker never gets lucky, or perhaps knows something neither of us do.
I'm not sure I'd use the death/dying of Moore's Law as a mitigation strategy :P
The people wanting to make it practical certainly won't use something as crude and slow as Spectre or Meltdown or this. They just own your entire system.
