|
|
|
|
|
|
by theicfire
1472 days ago
|
|
|
Hmm, it feels like Intel/AMD are ducking and just hoping that the implications of this are not large. Here's a video from Intel chatting with the researchers: https://community.intel.com/t5/Blogs/Products-and-Solutions/... The questions are incredibly weak from the interviewers. They first state that it's not practical because the attack could take many hours, even days. But they don't describe why a day-long attack is not practical. They then bring the researchers and ask them the same question. The researchers say that the attack is very practical because it only takes.. a few hours or days to execute the attack. Here's the specific part: https://youtu.be/BiRPr839dSU?t=1476 Instead of chatting more about this discrepancy they just ignore it and ask the researches how they feel about their new popularity. From what I can tell from the advisory from Intel, it's simply that people should understand the attack and mitigate it in software. It's very vague. The specifics (i.e. a list of example popular programs that are vulnerable) seem entirely missing. |
|
|
In engineering, the word "practical" has an expansive definition that takes into account end goals, likely costs, rewards and risks of getting there, whether better approaches exist and so on. In academic cryptography the word practical is used far more narrowly and means something like: this algorithm doesn't only exist on a whiteboard, we wrote a toy implementation of it as well.
There are people in this thread telling each other how to disable power scaling and stuff. They're probably people who take the claim of "real and practical" literally without realizing what this does(n't) mean when coming from academics. If you read the paper you'll notice a lot of aspects about the attack that aren't actually practical at all, so to believe this is a threat worth spending time on requires a lot of assumptions about unknown developments that may not hold.
To name just a few aspects of "practicality" that engineers might care about but the paper authors do not:
1. The attack requires DoSing the target server for extended periods, like days at a time, without being detected. Do you have CPU load or bandwidth monitoring in place? Then you're going to detect the attack within minutes of starting before it got anywhere at all and can simply block the attacking IPs.
2. The attack is only demonstrated against specific crypto libraries and algorithms that you're almost certainly not using. You're asked to assume it can be easily applied against normal algorithms, but their technique relies heavily on the exact mathematics and implementation schemes they're attacking, so it's not entirely obvious how easily it can be adapted. Presumably they chose this obscure target for a reason.
3. The attack was demonstrated on a perfectly unloaded system in which the server does nothing except cryptography and has no other users. Given how sensitive it is to tiny timing fluctuations, it seems like more or less any other activity would raise the noise level so much that days of DoS attacks might turn into months or years. You're asked to assume this isn't a problem for the attackers, but that seems like a very unsafe assumption.
4. The attack was demonstrated on a machine that's in the same datacenter as the machine being attacked (~600 microseconds of latency to the server). Are your machines in a private colo facility where the owners know who is renting their servers? Well then, the attackers are going to be pretty quickly detected and investigated by the authorities aren't they, because there are no valid use cases for DoSing a server right next to your own for days at a time with carefully crafted crypto packets.
5. What about the cloud? Pretty easy to get machines there, but you also can't control whereabouts you get placed. I read another paper where researchers tried to do remote timing attacks on machines in AWS. It requires massive amounts of descheduling and rescheduling VMs in the hope that eventually you get lucky and the scheduler places you near enough to the victim. That pattern is extremely distinctive, has no real legitimate use cases and AWS could very easily detect and it shut it down if this sort of attack ever became an actual problem. But of course, such obvious mitigations don't get mentioned in these papers.
6. Is this really the easiest way to snoop on traffic? Why not just search for a classical vuln in the client or server software itself? It's not like there's a shortage of those. Just weeks ago it turned out Jira was vulnerable because it was shipping a library last updated in 2005. If this attack is the best way to achieve a specific goal it means you're going up against an unusually well hardened target such that all other means of entry like phishing, hacking, government intervention, physical attack etc are less practical than this. Very few organizations will meet that level of security.
As you can see, once you expand the definition of "practical" to include consideration of everything a real attacker would care about end-to-end, like not being detected, and succeeding against real servers doing actual work that are monitored by humans, the whole thing starts to look very questionable indeed.
Frankly I find it a bit irresponsible that they've named it Hertzbleed. The original Heartbleed attack was quite practical and let you dump the memory contents of real world servers at will. People demoed it on random Cloudflare edge nodes and the like. It required an immediate response by many, many people. Now we have a website that looks nearly identical to the Heartbleed website - it has a similar name, a a logo, a similar FAQ, talk of "patches" by CPU vendors, etc. But when we read the paper there's no similarity between the attacks really. It's just another case of academics exaggerating their work for the sake of getting a paper and it needs to stop.