Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

Post reply on HN
Print view View original

231–240 of 406 posts

Re: Hertzbleed Attack

#231

Post by goodpoint »

gambiting wrote: post #227
goodpoint wrote: post #221

Earlier quoted context omitted.

> 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.

The other way of looking at it is that a huge portion of the market is running non-ECC ram and it hasn't resulted in any measurable reduction of security or stability of operating systems worldwide. So maybe it really isn't necessary for your average user, and manufacturing ECC ram for users who ultimately don't need it would be just a waste(both financial and environmental).

> hasn't resulted in any measurable reduction of security or stability of operating systems worldwide

Except it did.

Re: Hertzbleed Attack

#233

Post by Syonyk »

nickelpro wrote: post #213
CamperBob2 wrote: post #205

Earlier quoted context omitted.

I think the one-dimensional severity classification is part of the problem. If you're running a cloud provider, it's a much bigger deal. Call it "high severity" issue for those use cases. No objection to that, better safe than sorry. Probably 90% of PCs are single-user Windows desktops, though. It's a "nonexistent severity" issue for those use cases... yet we all get to pay.

Fully concur, although now that I've read some of the white paper some of this doesn't even appear to be a real issue? Like the claimed "remote" attacks against, "Cloudflare’s Interoperable Reusable Cryptographic Library (CIRCL) [28], written in Go, and Microsoft’s PQCrypto-SIDH [65], written in C ... [are] meant to run in constant time" But they just straight up don't run in constant time, so they're vulnerable to a…

> But they just straight up don't run in constant time, so they're vulnerable to a timing attack across the network. That's clearly just a library bug? Like surely the dumbest part of a "constant time" algorithm is double checking that you ran for a constant wall clock amount of time?

It's... hard. A lot of the "constant cache behavior" and "constant time behavior" algorithms were written back in the day when the CPU speeds didn't change randomly on you, or at worst toggled between "idle" and "running hard." Think... oh, even the Core 2 days, really. They didn't switch that fast.

And then the hardware behavior changed out from under the algorithms, and nobody noticed. Now the throttling is far more rapid. So they may still be "constant instruction count," but that no longer implies constant time.

It's... complicated. :( And what's worse, even the people in charge of managing the complexity don't understand all the details anymore. When stuff like this surprises Intel, we've got problems.

Re: Hertzbleed Attack

#234

Post by R0b0t1 »

bob1029 wrote: post #14

Something about this doesn't bother me as much as other side channels. To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any m…

It's more like discerning the washing machine based on the power meter, but you know exactly when and how many washing machines turn various bits on and off.

Could be doable, with some expensive equipment.

For the ghost side channel attacks we did see in situ proofs of concept. It's an open question how many people have the skill to do either those side channel exploits or the power meter washing machine guess above and are also engaged in crime.

Re: Hertzbleed Attack

#235

Post by jfk13 »

goodpoint wrote: post #229
jfk13 wrote: post #148

Earlier quoted context omitted.

How many people can reliably identify "sensitive data", do you think?

Enough to collect and handle such data in the first place. Or do you handle data without knowing what it is?

I suspect ideas of what is "sensitive" vary greatly. Whose definition counts?

Re: Hertzbleed Attack

#236

Post by lossolo »

BoppreH wrote: post #176
xoa wrote: post #155

Earlier quoted context omitted.

OK, but can you walk me through the threat model here? This isn't a rhetorical question, it's easy to see how servers in general and shared hosting, colocated VMs etc in particularly might theoretically face a threat here, I'm just trying to get a better understanding of how GP would be correct for end user devices. The individual in question on the smartphone or computer specifically chooses to initiate a connection…

The exploit comes from a hacked server, a bad ad, social engineering, etc. As for the attack, imagine a browser that encrypts local storage with a system key. If I understand correctly, by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data. This might sound very theoretical, but modern OS'es (and password managers) have lots of keys like that. There's…

> imagine a browser that encrypts local storage with a system key. If I understand correctly, by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data.

Don't you need precise clocks for this in JS? The ones that were disabled in browsers after Meltdown/Spectre.

Re: Hertzbleed Attack

#237

Post by saagarjha »

samstave wrote: post #230
vore wrote: post #223

Earlier quoted context omitted.

This is about measuring CPU frequency, where doing so definitely does not cause your computer to explode.

Quoted post unavailable.

Being unnecessarily cryptic and sounding like a crackpot while calling everyone else out for being uninformed is generally unlikely to get you support on Hacker News.

Re: Hertzbleed Attack

#238

Post by jabart »

_0w8t wrote: post #204
bobkazamakis wrote: post #147

Earlier quoted context omitted.

> the attacker does in fact need to be able to get the targeted system to run something somehow >Unfortunately that includes Javascript, and now that affects virtually everybody. Debatable -- not because of the goofballs who insist on never running javascript, but because it doesn't have the necessary clock precision available.

When Spectre came it turned out that it was very straightforward to implement the relevant attacks in JS. A script can use workers with shared memory access to monitor execution and get a timer with less than 100ns resolution. As the result the shared memory were disabled. Later under the presumption that relevant issues were mitigated, the shared memory was re-enabled again. So I wonder if the shared memory will be…

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 returned time to 1 millisecond increments."

Re: Hertzbleed Attack

#239

Post by dan000892 »

vore wrote: post #223
samstave wrote: post #208

Earlier quoted context omitted.

Quoted post unavailable.

This is about measuring CPU frequency, where doing so definitely does not cause your computer to explode.

OR DOES IT???

Oh, it doesn’t? Carry on.

I’m quite fatigued by the recent (?) increase in comparisons of current vulnerabilities, attacks, and adversarial capabilities to Stuxnet and can’t help but tune out when it’s invoked. Yes, the ‘96 Bulls were the best team of all time. That has no bearing on how good the Bulls are now and sure as hell shouldn’t blind you to how good other teams have gotten since…

Re: Hertzbleed Attack

#240

Post by NamTaf »

samstave wrote: post #208
omginternets wrote: post #207

Earlier quoted context omitted.

Could you elaborate?

Quoted post unavailable.

This has almost no similarities to stuxnet. A more analogous hypothetical attack to stuxnet would be if they repeatedly cycled spinning rust drive heads in a certain way to cause the motors to fail and corrupt data, all the while faking the SMART data of the drive to not report drive head parking cycles.

Your understanding of either this attack and/or stuxnet is flawed.

Post reply on HN