6 ms·

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.

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.

yomkippur 4y ago
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.
- pishpash 4y ago
  Use physical tokens. Passwords is not the future.
  - MBCook 4y ago
    Is that an option for the root password on Linux?
    - SkyMarshal 4y ago
      Yeah, for example: https://support.yubico.com/hc/en-us/articles/360018695819-Ubuntu-Linux-20-Login-Guide-Challenge-Response https://support.yubico.com/hc/en-us/articles/360018695819-Ub...
      - Hackbraten 4y ago
        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 4y ago
        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.
- nomel 4y ago
  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/e4fcee00cb6d82874dace72106d73fef https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...
  - amelius 4y ago
    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.
  - yomkippur 4y ago
    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 4y ago
      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.
XorNot 4y ago
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?
- NovaVeles 4y ago
  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.
- jlokier 4y ago
  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-frequently-asked-questions?lang=en https://developer.arm.com/documentation/102587/0102/General-... https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability https://developer.arm.com/Arm%20Security%20Center/Speculativ...
- okanat 4y ago
  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?
ec109685 4y ago
Password managers for every other password seem vulnerable?
- YZF 4y ago
  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.
woojoo666 4y ago
So M1 macbooks are safe?
- ncmncm 4y ago
  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.
avianes 4y ago
> 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 4y ago

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.

pishpash 4y ago
Use physical tokens. Passwords is not the future.
- MBCook 4y ago
  Is that an option for the root password on Linux?
  - SkyMarshal 4y ago
    Yeah, for example: https://support.yubico.com/hc/en-us/articles/360018695819-Ubuntu-Linux-20-Login-Guide-Challenge-Response https://support.yubico.com/hc/en-us/articles/360018695819-Ub...
    - Hackbraten 4y ago
      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 4y ago
        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.
nomel 4y ago
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/e4fcee00cb6d82874dace72106d73fef https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...
- amelius 4y ago
  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.
- yomkippur 4y ago
  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 4y ago
    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.

XorNot 4y ago

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?

NovaVeles 4y ago
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.
jlokier 4y ago
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-frequently-asked-questions?lang=en https://developer.arm.com/documentation/102587/0102/General-... https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability https://developer.arm.com/Arm%20Security%20Center/Speculativ...
okanat 4y ago
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?

ec109685 4y ago

Password managers for every other password seem vulnerable?

YZF 4y ago
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.

woojoo666 4y ago

So M1 macbooks are safe?

ncmncm 4y ago
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.

avianes 4y ago

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