To my knowledge there are currently no known exploits. It's more a matter of risk management: newer codebases are less secure because we had less time to find bugs and spread best practices. That problem is amplified for larger codebases (but diminished by a more active developer community).
Trivial, yet nobody has managed to produce a working exploit that doesn't require a running start. The poc exploits wouldn't work in the wild. They are running with interference of a real system.
Also, meltdown requires the data to be snooped to be in L1D cache. So the current demo exploit has to keep pushing the data into cache to be read.
Something simple like steal a password from sudo should be trivia right? I'd not convinced i need to worry.
And making non public facing machines pay the price of the mitigation seems like too much.
The person you are responding to is specifically talking about looking for exploits that are hidden behind compiler bugs or obfuscated by language features. So you're missing the point, I guess.
A single incident doesn't really demonstrate that it's "open to exploits"; it just demonstrates that it's possible, but no system is 100% foolproof so that's not really meaningful.
I can only recall two incidents: the other being the JS event-stream cryptothing and that was five years ago. Perhaps there are others I'm not aware of, but by and large, it seems very rare that projects that see real-world usage get compromised.
(and don't give me any of that "but we don't know how often it happens!"-bollocks – you can always say that about almost anything; go find evidence).
Interesting. I independently dreamt up this class of vulnerability in 2007 or so. I didn't know there were any instances of it in the wild. When I realized it ought to be possible, I just wrote a PoC vulnerable app and an exploit for it, and then sort of forgot about it. Cool to see it's a real thing now.
reply