Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

281–290 of 406 posts

Re: Hertzbleed Attack

#282
Isn’t the real long term mitigation here to do all crypto operations on a separate chip? Rewire platform libraries to use the TPM/SecureEnclave backends exclusively. Then if you need “soft crypto” you are kinda on your own in “you better know what you’re doing” territory?

Re: Hertzbleed Attack

#283

I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more…

I was rather disappointed as well. The original *bleed attack had private keys coming right out of the response stream, but this hasn't demonstrated anything close to that. Sure, the theory is sound but the practice seems to be more of an educational setup.

Re: Hertzbleed Attack

#284
post #125

Earlier quoted context omitted.

I’m a little confused about your attack vector - how feasible would you reckon it is to place such a malicious script on the largest public websites in existence, versus just getting the victim to install a Trojan? The latter could just literally monitor the user. I’m not saying your paper is technically wrong, just practically infeasible. Right now, you’ve chosen very specific websites. Have you explored if there is…

I don't think any of these side channels are really easy to pull off without the technical capabilities of a nation state or something similar. I personally think embedding a malicious script in a CDN (e.g. https://blog.ryotak.me/post/cdnjs-remote-code-execution-en/ ) that serves a script for a large website, or something similar ( https://blog.igorescobar.com/2016/08/21/ive-the-chance-to-tr... ), is more realistic t…

In my experience, large websites and most web apps don’t use CDNJS/etc, but bundle their code - this would make injecting your script much harder without a supply chain attack.

On second thought, given CORS I think this attack is actually impossible. How would your embedded script communicate your findings with your server? You would need to control the originating domain itself…

Re: Hertzbleed Attack

#285
post #238

Earlier quoted context omitted.

My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the…

Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?

I know next to nothing about the internals of how the rounding code works, but couldn't randomly choosing to round up or down mitigate this somewhat?

Re: Hertzbleed Attack

#287

I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more…

>we don't go feeding the paranoia machine and driving us even more towards the growing dystopia.

It's an academic research paper with a website and a logo, it's not like they're broadcasting on the 6pm news. Would you rather the research not be done at all? Or just not posted on the websites you visit?

Re: Hertzbleed Attack

#289

Earlier quoted context omitted.

This is engineering, there's a lot of things that could happen but don't, we don't all run ECC RAM either. The problem is that speculative execution is really good and if Intel didn't have it they would've been selling worse CPUs. And to be clear, it was about 20 years from the point where people were seriously publishing theories about speculative execution attacks to the point where it was a practical attack. Think…

> we don't all run ECC RAM either ...because Intel placed profit above user's needs and choose not to allow ECC on desktops. Similarly, many other things have been made insecure by plain greed.

I'll argue the opposing side. Can you imagine how little progress there would be if all CPU/Ram development were a government program?

Re: Hertzbleed Attack

#290
post #238

Earlier quoted context omitted.

My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the…

Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?

Isn't rounding pretty much the same thing as throwing away some precision in this case? So if I drop some (enough) bits and add .5 then no amount of averaging is going to recover the lost precision. Or maybe I misunderstand?
Post reply on HN