Technology

37712 readers

176 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago

MODERATORS

[email protected]

142

Encryption-breaking, password-leaking bug in many AMD CPUs could take months to fix (arstechnica.com)

submitted 1 year ago by [email protected] to c/[email protected]

19 comments fedilink hide all child comments

The bug allows attackers to swipe data from a CPU’s registers. […] the exploit doesn’t require physical hardware access and can be triggered by loading JavaScript on a malicious website.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 7 points 1 year ago (1 children)

Good writeup, but...

largest SIMD register on Zen2 is a 256bit register or 32 Bytes/characters. This exploit works by offering a half a register for unsuspecting processes to write data to, meaning 16 bytes/characters of data at a time. Please use passwords longer than 16 characters

This attack doesn't target passwords "typed by users", but AES binary passwords, which are either 128 or 256 bit long. Particularly it targets password used very often, like disk encryption passwords (both on end-user and server machines) or RAM encryption passwords (mostly used for securing VMs on servers).

What ends up in that register could be a password or cryptographic key, or it could be a chunk of HTML or a UUID, or who knows what.

It just happens that those same SIMD registers, are used to speed up encryption/decryption operations, so there is a very high chance of whatever data a malicious program manages to extract, to be either part of the key (about 30% chance), part of some random data either encrypted or decrypted (about 30% each), or a small chance of something else.

there is no way to target specific processes

when you are running javascript in a browser, you don't get as fine grained control over the host processor and the timing

Given that the attack can be executed millions of times per second, even with a low chance of hitting the right timing, the "beauty" of these attacks is that most of the time you will get the same data, which will be either detectable as "unsuccessful", or part of the disk/RAM encryption password. Simply running them for long enough, then looking at which data repeated the most, is going to give you the passwords to the most often running encryption processes.

The difference in impact to servers vs. user machines, is only because a server running the same software 24/7 is more likely to return meaningful data, than a user opening and closing random browser tabs, playing games, or turning the whole thing off.

Still, if the user has disk encryption enabled, that key is likely to be extracted even with a piece of JavaScript that fails the attack most of the time.

[–] [email protected] 3 points 1 year ago (1 children)

I suppose that is a good point. look for repeating chunks of data to get hardware encryption keys. However, the main point I want to stress remains that a javascript version is yet to be proven. Cloudflare edited their original statement yesterday from "The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server." to today "While there might be a possibility to execute this attack via the browser on the remote machine it hasn’t been yet demonstrated." https://blog.cloudflare.com/zenbleed-vulnerability/

This was the main piece of misinformation I wanted to dispel. It is still up in the air whether regular people with home computers need to be panicking. Thank you for also pointing out that this isn't primarily targeting passwords "typed by users."

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago) (1 children)

The JavaScript vector is a reasonable extrapolation based on how similar attacks like Meltdown, Spectre, or Heartbleed, eventually got their JavaScript exploits. There may not be one yet, but there's likely to be one at some point.

It is still up in the air whether regular people with home computers need to be panicking.

That one's easy: no, they don't.

Even if an attacker were to get the disk encryption key from a regular user through some malicious JavaScript, the chances of them being able to actually exploit it, are slim to none. They'd still need some extra way to use that key, which would require a separate exploit, or physical access.

If it were a company computer, or the user got personally targeted (espionage, trade secrets, law enforcement, etc.)... then maybe worry a bit.

Hosting providers with shared servers, need to panic a lot. Anyone running a public server, be it at a provider or at home, should also panic a bit.