I've been getting a few questions about the recent "PortSmash" vulnerability announcement. Short answer: This is not something you need to worry about. If your code is vulnerable to it, you were already vulnerable to other (easier) attacks.
-
Show this thread
-
While it's great to see that someone put together exploit code for this, it's not a new discovery: I described this attack in 2005 when I first exposed the dangers of shared resources in Intel Hyperthreading.
1 reply 2 retweets 13 likesShow this thread -
I didn't write exploit code at the time because this attack only works when the sequence of instructions bring executed depends on sensitive information; and if that's the case you're already leaking information in many other ways (code cache, data cache, branch prediction...).
1 reply 0 retweets 8 likesShow this thread -
The defence against PortSmash is exactly the same as the defence against microarchitectural side channel attacks from 2005: Make sure that the cryptographic key you're using does not affect the sequence of instructions or memory accesses performed by your code.
2 replies 1 retweet 11 likesShow this thread -
Replying to @cperciva
Not just the key, the secret data too! This is the right advice, but it's very unsatisfying. It's still too hard to write and verify this kind of code, and sometimes coding mistakes there are bigger problems than the side channels they were designed to fix.
1 reply 0 retweets 1 like -
Replying to @colmmacc
Keys are generally more sensitive than data; but yes, it should all be kept secure. I've been asking compiler authors for 13 years to give us better tools, e.g. to mark variables as "cannot be used in control flow or address computation". Alas, no progress yet...
2 replies 1 retweet 2 likes -
Maybe Amazon can find some smart compiler people and get them to do this? It would help everybody's security. ;-)
1 reply 0 retweets 0 likes
LuckyMinus20 changed my mind on that. The branch free code fixes for Lucky13 went through a lot of review, loads of eyes, and patched a vulnerability. But then it unintentionally regressed within 18 months.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.