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.
-
Show 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 -
Replying to @BRIAN_____ @cperciva
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.
0 replies 0 retweets 0 likes -
Replying to @BRIAN_____ @cperciva
The LuckyMinus20 was a logic error, and worse than the Lucky13 side-channel (IMO), at least for TLS (not DTLS). That's what I mean when I say it's too hard to write this kind of code without risking worse problems.
1 reply 0 retweets 1 like
http://www0.cs.ucl.ac.uk/staff/b.cook/VSSTE18_sidetrail.pdf … can catch the LuckyMinus20 regression, we actually used it as a target case. It needs more than the secret modifier, it also needs to know the entry and exit points, but since the logic error is data-dependent, it can catch it too.
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.