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

321–330 of 406 posts

Re: Hertzbleed Attack

#321

Post by doublepg23 »

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

Google researched the topic over 2.5 years last decade and did find a notable amount [1]. "Bitsquatting" has also been seen in the wild in the past decade [2].

[1] https://static.googleusercontent.com/media/research.google.c...

[2] https://en.wikipedia.org/wiki/Bitsquatting

Re: Hertzbleed Attack

#322

Post by slimsag »

mintplant wrote: post #319
lossolo wrote: post #236

Earlier quoted context omitted.

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

A lot of that has since been rolled back as different mitigations have been deployed against Spectre.

Source? The MDN is very clear about precise timing not being available due to Spectre mitigations.

Re: Hertzbleed Attack

#323

Post by sterlind »

bayindirh wrote: post #162
mcronce wrote: post #146

Earlier quoted context omitted.

I was thinking about busy servers running mixed workloads. I would think that, with the CPU running a bunch of workloads on different cores, context switching, etc, it wouldn't be a practical attack. Maybe that's incorrect. Mostly idle servers are a different story, obviously.

Sometimes response critical VMs are pinned to the cores at the hypervisor level, and intel's chips support independent (frequency) scaling of CPU cores for some time. In that scenario, mixed loads won't help. You'll have at least one pinned core, and it can scale relative to the VMs load (considering you also pin hypervisor cores, etc). So, it's possible to hit that pinned core and execute the same timing attack. I k…

unless you do something special, a lot of interrupts are handled by CPU 0. there's techniques like Receive-Side Scaling to balance this load across the cores but that's specific to NICs.

Re: Hertzbleed Attack

#324

Post by CodeArtisan »

kube-system wrote: post #10

I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.

Returning earlier in a procedure or breaking a loop once a condition is met give inconstant time allowing to retrieve, for example, a password.

Here an example in python: https://ideone.com/W24UZW

Re: Hertzbleed Attack

#325

Post by bayindirh »

sterlind wrote: post #323
bayindirh wrote: post #162

Earlier quoted context omitted.

Sometimes response critical VMs are pinned to the cores at the hypervisor level, and intel's chips support independent (frequency) scaling of CPU cores for some time. In that scenario, mixed loads won't help. You'll have at least one pinned core, and it can scale relative to the VMs load (considering you also pin hypervisor cores, etc). So, it's possible to hit that pinned core and execute the same timing attack. I k…

unless you do something special, a lot of interrupts are handled by CPU 0. there's techniques like Receive-Side Scaling to balance this load across the cores but that's specific to NICs.

However, I can pin a VM to far away cores to CPU0 (e.g. socket 3, cores 20-23), hence isolating it from all the interrupt handling, and attack that VM instead, at least in theory, no?

Re: Hertzbleed Attack

#326

Post by xurukefi »

hinkley wrote: post #49

I suspect what we are seeing in the last few years is the slow death of purely symmetric multiprocessing. At the end of this I wonder if we'll see processors with one or two cores dedicated to cryptographic primitives, where the ALU has a fixed IPC, the core has a very limited number of clock rates, and the caches are sized to prevent eviction when running common cryptographic algorithms.

Unfortunately, side-channel attacks like this (or like Meltdown, Spectre, TLBleed, Foreshadow, etc...) only have negligible real-world impact. They are very interesting from a theoretical point of view, but are usually totally impractical for a plethora of reasons. Therefore, chip designers aren't really pressured into thinking about new chip designs. The sad reality is that something like Log4Shell, which is super boring from a theoretical point of view, is much more practical for attackers to exploit.

Re: Hertzbleed Attack

#327

Post by throwaway742 »

2OEH8eoCRo0 wrote: post #228
MrWiffles wrote: post #2

Brilliant approach, really. Never occurred to me to try something like this! Are you affected? Very likely. What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) One thing I found interesting that may get changed later, so I'm documenting it here, is in their FAQ they…

You can configure your CPU to always boost if you're really paranoid. It shouldn't run much hotter since the load doesn't increase, just the frequency.

Then why isn't that the default setting?

Re: Hertzbleed Attack

#329

Post by robocat »

sterlind wrote: post #323
bayindirh wrote: post #162

Earlier quoted context omitted.

Sometimes response critical VMs are pinned to the cores at the hypervisor level, and intel's chips support independent (frequency) scaling of CPU cores for some time. In that scenario, mixed loads won't help. You'll have at least one pinned core, and it can scale relative to the VMs load (considering you also pin hypervisor cores, etc). So, it's possible to hit that pinned core and execute the same timing attack. I k…

unless you do something special, a lot of interrupts are handled by CPU 0. there's techniques like Receive-Side Scaling to balance this load across the cores but that's specific to NICs.

Is that because CPU 0 tends to be scheduled by default? Or is that because the CPU usually uses core CPU 0, and Linux schedules to different cores?

Redhat Linux docs[1]:

The /proc/interrupts file lists the number of interrupts per CPU per I/O device. It displays the IRQ number, the number of that interrupt handled by each CPU core, the interrupt type, and a comma-delimited list of drivers that are registered to receive that interrupt.

The default value for smp_affinity is f, meaning that the IRQ can be serviced on any of the CPUs in the system. To view use cat /proc/irq/32/smp_affinity for interrupt 32 as example. Setting this value to 1, like echo 1 >/proc/irq/32/smp_affinity, means that only CPU 0 can service interrupt 32.

[1] https://access.redhat.com/documentation/en-us/red_hat_enterp...

Re: Hertzbleed Attack

#330

Post by arpafaucon »

SOLAR_FIELDS wrote: post #285
contravariant wrote: post #245

Earlier quoted context omitted.

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?

If you round up and down with the same probability, it will get canceled on the long run.

I suppose this does mitigate the risk a little, but risks breaking other things. For example, you don't have the simple logic sequence: a round(a) So I'd say "not worth it"

Post reply on HN