[photon-torpedo]

The root password hash is not sufficient to log in as root, but knowing the hash enables an attacker to run an offline brute-force attack to crack the password. Depending on the password complexity, this may or may not be feasible.

That said, this attack may be able to extract other information from system memory that would enable de-facto root access, it depends a lot on what's running on the machine.

> What can we do?

Install the patches and enjoy the reduced performance. Or run Linux on ARM, and hope that noone will find similar exploits in the ARM architecure.

[avianes]

> Or run Linux on ARM, and hope that noone will find similar exploits in the ARM architecure

It's a micro-architecture exploit, nothing specific to the x86 architecture. I highly suspect that some ARM implementations are also vulnerable to this exploit.

As long as return instructions can trick the Branch Preduction Unit (BPU) to produce a speculative return address that is not from the Return Stack Buffer (RSB), then return instructions can potentially be exploited to perform Branch-Target-Injection (Spectre V2). (I simplify it because there are other conditions such as the ability to set the injected branch address produced)

[yomkippur]

So how complex does the password need to be?

What if you have a 32 character password with mostly symbols, punctuations and non sensical strings mixed together?

It seems like as quantumn computing gets better it would be a matter of time for them to crack any password going forward.

Do we need an entire passage of the bible transformed into a password? I just assume it would be a lot more difficult to find the chimpanzee on the typewriter that can write a page from the bible purely by trial and error. That would take light years is my thinking but I could be wrong.

[nomel]

For an Nvidia 3090, you you can do around [1]:

MD5: 65 trillion guesses/second

SHA-512: 2 trillion guesses/second

Blowfish: 100k guesses/second

My root password is fairly short, since I type it all the time. I would be screwed if anyone had interest. I don't think relatively short root passwords are all that uncommon.

1. https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...

[nneonneo]

Nitpick: that’s bcrypt, not Blowfish. Blowfish is an encryption algorithm; bcrypt is a password hashing algorithm based on Blowfish, but designed to be significantly slower.

[BeefWellington]

Also, bcrypt comes with a work factor that works on a log scale -- a work factor of 6 is 2^6 (64) rounds, and 6 is considered far too out of date these days. The default in hashcat is (IIRC) a work factor of 5 (2^5, 32 rounds).

If you're using 14 or higher, which is usually the recommendation thrown around these days, that 100k number will look more like single or double digits.

[yomkippur]

I assume these are for very short passwords? It dramatically increases in complexity with just a few extra characters, is it possible then to use a password that is 3~4 sentences long to defeat this?

5 characters (3 lowercase letters, 2 numbers) 365= 60,466,176

7 characters (1 capital letter, 6 lowercase letters) 527= 1,028,071,702,528

8 characters (4 lowercase letters, 2 special characters, 2 numbers)

688= 457,163,239,653,376

so in about 10 seconds it would be able to discover the latter which is absolutely insane to me. The only way is to increase the letters and special characters.

for instance a 12 character password (8 lowercase letter, 2 special, 2 #) would yield an unwieldly number of possibilities but given you can brute force 65 trillion per second at the lower end, we would be seeing an astronomical figure.

We might also see this brute force capacity dramatically increase thanks to Moore's law and then the sky is truly the limit.

a 32 character password would be broken within our lifetime in just a matter of years.

[13of40]

Or use multiple rounds of hashing to generate and validate the hash. IIRC about 5 years ago MS Office was using 500K rounds of SHA512 by default (as a keygen for decrypting documents), which meant about 8 guesses a second on a good machine. Of course you have to keep updating those specs as computing power increases over time.

[yomkippur]

Is there anything stronger than blowfish? seems like I would just do that 50,000 rounds of blowfish mixed with SHA512 rounds in between randomly. Good luck trying to brute force an excerpt from the Bible written in Japanese backwords using esoteric usage of special characters to top it off.

I expect this to take at least a few millenias to crack

[nomel]

Every time your password is used, you will experience that hash delay. So, for usability, it would be best to keep it to something not-annoying, and just change your password every once and a while.

[yencabulator]

> Is there anything stronger than blowfish?

I think you mean bcrypt..

Both Argon2 and scrypt win over that:

https://github.com/P-H-C/phc-winner-argon2 https://www.tarsnap.com/scrypt.html

[GoblinSlayer]

>a 32 character password would be broken within our lifetime in just a matter of years

Won't you make much more profit spending those resources on mining bitcoin? And where do you plan to get energy to run that calculation even if you hypothetically had enough performance?

[amelius]

Don't forget that you first need to figure out where the root pw hash starts and ends in the stream of data that you receive from this hack.

[pishpash]

Use physical tokens. Passwords is not the future.

[MBCook]

Is that an option for the root password on Linux?

[SkyMarshal]

Yeah, for example: https://support.yubico.com/hc/en-us/articles/360018695819-Ub...

[Hackbraten]

What would keep a side-channel attacker from reading your YubiKey PIN from kernel memory, and then racing all your authentication attempts until it manages to win the physical button event?

[SkyMarshal]

Nothing maybe. But if a side-channel attack gains access to kernel memory, they can do just about anything, and no login scheme is secure against that.

[woojoo666]

So M1 macbooks are safe?

[ncmncm]

Hahahaha. No.

But people after volume break-ins might consider it obscure enough not to bother with. "State actors" are often more comprehensive, because they don't want to get blocked from a designated target by such incidentals.

[ec109685]

Password managers for every other password seem vulnerable?

[YZF]

Depends on how long the decrypted password(s) is sitting there for someone to read and how easy it is to locate... at least that'd be my speculation. You'd think a good password manager doesn't hold onto the password for very long, then there's copy/paste buffers (which some password managers also clear), then there's the question of whether there's enough information for the attacker to figure out what the password is for. If this is a JavaScript attack vector (not sure if this is possible at all given the language constraints) it's presumably a lot slower vs. the numbers discussed.

So maybe don't quite panic yet. Developing story.

[XorNot]

I am curious if there's any evidence ARM is fundamentally immune to this sort of exploit, or if we're just not looking hard enough yet?

[jlokier]

ARMs are vulnerable to several spectre-style exploits, and have mitigations that can be turned on at some cost to performance just like x86.

Links to ARM FAQs and other docs below. Note that ARM's list of vulnerable implementations doesn't account for third party designs eg Apple CPUs.

https://developer.arm.com/documentation/102587/0102/General-...

https://developer.arm.com/Arm%20Security%20Center/Speculativ...

[NovaVeles]

I would suspect it is a case that folks just aren't looking hard enough yet. There is also the massive fragmentation in the ARM space. Something like M1/M2 being a much more consistent target.

It could also just be that they have designed them better but time will tell. A lot of things looked really secure until they suddenly were not.

[okanat]

ARM chips are mainly much simpler. The fight with Spectre-like side-channels is a fight against thermodynamics we cannot win, only mitigate.

Any performance improvement relies on the patterns of data also exposes the data itself. Intel and AMD wanted to make faster returns by analyzing the patterns in the return instructions by putting a branch prediction logic. When they do that it behaves differently depending on the data hence it is "observable" to outside world.

If any ARM manufacturer implements a similar feature, it will be vulnerable. There is only one question: When will it be practically exploitable?