5 ms·
Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrat
by Xylakant 9y ago
Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector.
It’s also strictly speaking not a privilege escalation, it’s “see things you’re not supposed to.”, such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.
- lisper 9y ago> JavaScript ... is a demonstrated attack vector OMG, I didn't know that. Thanks.
- Tuna-Fish 9y agoJS as an attack vector can be effectively mitigated by denying access to high-precision timers (and a few features that can be used to construct high-precision timers). At least Chrome and Firefox are doing this, so just make sure that you are keeping your browser up to date. If you feel paranoid, you might also want to disable JS by default and only enable by whitelist on any machines that hold particularly sensitive or valuable data.
- rolux 9y agoKeeping JavaScript from constructing high-precision timers is going to be a cat and mouse game. See the "Fantastic Timers" paper. Link to HN discussion: https://news.ycombinator.com/item?id=16080235 https://news.ycombinator.com/item?id=16080235
- Xylakant 9y agoAlso: if you don’t have high precision timers, you probably could also go and increase the number of guesses to cancel out noise. After all, this is a statistical side channel attack. This will be fun for quite some time.
- Tuna-Fish 9y agoDoing that is harder than usual, because the time before rollback is very limited, reducing the amount of cache lines you can pull into the cache and you can measure a given cache line only once. The attack is already pretty damn slow (1kB/s) in C, if you have to collect a statistically significant sample in JS it might well slow down enough to not really work properly.
- craigyk 9y agoIt also consumes lots of CPU to scan memory this way, so just be on the lookout for webpages consuming lots of unexpected CPU.
- dgoldstein0 9y agoYeah, it's possible to use to bypass same origin policy and read data across origins. Basic idea is that most browsers have multiple origins in the same process, meaning that the same speculative execution + optimistic caching can leak data to js from another origin in the same process.
- ahakki 9y ago> JavaScript […] is a demonstrated attack vector Does that mean that we are soon going to be vulnerable to remote exploits via WASM as well? Do mitigation attempts such as reducing the JavaScript timing resolution aslo apply to WASM?
- keyme 9y agoThey do apply to WASM. However, these mitigations are hardly air tight. I'd expect new exploits anyways.
- Xylakant 9y agoAll that these mitigations did was disable all obvious precise timers. All you need for a new attack is a novel way to create a precise timer. And since it’s now known how valueable such a timer would be, I’m certain that minds more clever than me will take a shot at this.
- deleted 9y ago[deleted]
- kazinator 9y agoIf one of the secrets you see is the contents of a buffer containing a password, it might then be a privilege escalation.