5 ms·

Whats the security implication of leaking the root hash?

by dtx1 3y ago

K0nserv 3y ago
With the root hash you can crack the root password using tools like John The Ripper[0]. More generally, I assume, this exploit can be used to read any arbitrary files on the system, bypassing regular access control, and plenty of other stuff you aren't supposed to be able to do as a non-privileged user. 0: https://www.openwall.com/john/ https://www.openwall.com/john/
- rsaxvc 3y ago
  It seems like this would only allow reading memory resident for some other reason. Still bad, but I do not think it would allow directly reading files that weren't already in memory. As for /etc/shadow, it would be loaded any time someone attempts to login, and might even stick around in the page cache...
kimixa 3y ago
I'd guess it's not restricted to the /etc/shadow file and could leak the contents of "any" memory in the system - that is just used as an example that can be (relatively) easily searched for in memory due to having a rather unique pattern. I'm a little confused about the presentation of this - I think a fair bit of work has been put into the presentation and make it look "hacker" rather than actually required for the exploit, which doesn't fill me with confidence, but I guess we'll see when the actual description gets released. Like why is the shell loop re-building the exploit code? The output seems strangely character rate-limited but extremely even when if it was being rate-limited by the exploit itself I'd expect more noise if it relies on some probability to read the memory contents, and absolutely no description of the technique itself.
- K0nserv 3y ago
  > I'm a little confused about the presentation of this - I think a fair bit of work has been put into the presentation and make it look "hacker" rather than actually required for the exploit, which doesn't fill me with confidence, but I guess we'll see when the actual description gets released. > Like why is the shell loop re-building the exploit code? The output seems strangely character rate-limited but extremely even when if it was being rate-limited by the exploit itself I'd expect more noise if it relies on some probability to read the memory contents, and absolutely no description of the technique itself. This team has done stuff like this before, they were behind Retbleed[0], for which they released a similar style video[1], last year. I expect more details will follow after the USENIX Security Symposium. 0: https://comsec.ethz.ch/research/microarch/retbleed/ https://comsec.ethz.ch/research/microarch/retbleed/ 1: https://www.youtube.com/watch?v=dmSPvJxPm80 https://www.youtube.com/watch?v=dmSPvJxPm80
thevania 3y ago
when you look properly at the end of the video the root hash starts with $y$ implying its yescrypt more info here https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en... https://www.openwall.com/yescrypt/ https://www.openwall.com/yescrypt/ once you have the hash you have to use some rainbow tables if they exist for that hash function or bruteforce it the authors of yescrypt claim: "Technically, yescrypt is the most scalable password hashing scheme so far, providing near-optimal security from offline password cracking across the whole range from kilobytes to terabytes and beyond. " in any way, this is a local attack, someone / some software on your local machine would need to execute it so i am not overly stressed, password hashes leak all the time from all different sources yet, it does worry me because my AMD stock is dropping on value because of this today :D
- CodesInChaos 3y ago
  Rainbow tables are only applicable to unsalted hashes (or possibly to ones with tiny salts). They are so rarely applicable, that I wouldn't even bother mentioning them. On that list, NT is the only completely unsalted hash, plus DEScrypt and its variants might still be susceptible with its 12 bit salt. Like all decent password hashes, yescrypt is salted.
  - deleted 3y ago
    [deleted]
- nneonneo 3y ago
  fwiw, yescrypt uses a salt so it will not be vulnerable to rainbow tables, and it is a slow hash so it won’t be that easy to bruteforce. A good strong password with a good hash function should remain secure even if the hash leaks.
barbito 3y ago
It's just an example. If you can leak kernel Memory you leak every process memory. So for example you can leak the content of a running browser
e12e 3y ago
> Whats the security implication of leaking the root hash? That you can try to crack the hash off-line with something like hashcat. For a random, salted, 22 character password (roughly log2(62^22)~130 bits of entropy, no rainbow tables because of the salt) - it might not be game over. On the other hand - if you can make an educated guess at the password - it's now trivial to check a few million variations without having to try to log in. As other's mentioned - reading arbitrary memory is probably worse (eg keyboard buffer, getting the plaintext password if a user logs in...).

Whats the security implication of leaking the root hash?

by dtx1 3y ago

Whats the security implication of leaking the root hash?

With the root hash you can crack the root password using tools like John The Ripper[0]. More generally, I assume, this exploit can be used to read any arbitrary files on the system, bypassing regular access control, and plenty of other stuff you aren't supposed to be able to do as a non-privileged user. 0: https://www.openwall.com/john/ https://www.openwall.com/john/

rsaxvc 3y ago
It seems like this would only allow reading memory resident for some other reason. Still bad, but I do not think it would allow directly reading files that weren't already in memory. As for /etc/shadow, it would be loaded any time someone attempts to login, and might even stick around in the page cache...

kimixa 3y ago

I'd guess it's not restricted to the /etc/shadow file and could leak the contents of "any" memory in the system - that is just used as an example that can be (relatively) easily searched for in memory due to having a rather unique pattern. I'm a little confused about the presentation of this - I think a fair bit of work has been put into the presentation and make it look "hacker" rather than actually required for the exploit, which doesn't fill me with confidence, but I guess we'll see when the actual description gets released. Like why is the shell loop re-building the exploit code? The output seems strangely character rate-limited but extremely even when if it was being rate-limited by the exploit itself I'd expect more noise if it relies on some probability to read the memory contents, and absolutely no description of the technique itself.

K0nserv 3y ago
> I'm a little confused about the presentation of this - I think a fair bit of work has been put into the presentation and make it look "hacker" rather than actually required for the exploit, which doesn't fill me with confidence, but I guess we'll see when the actual description gets released. > Like why is the shell loop re-building the exploit code? The output seems strangely character rate-limited but extremely even when if it was being rate-limited by the exploit itself I'd expect more noise if it relies on some probability to read the memory contents, and absolutely no description of the technique itself. This team has done stuff like this before, they were behind Retbleed[0], for which they released a similar style video[1], last year. I expect more details will follow after the USENIX Security Symposium. 0: https://comsec.ethz.ch/research/microarch/retbleed/ https://comsec.ethz.ch/research/microarch/retbleed/ 1: https://www.youtube.com/watch?v=dmSPvJxPm80 https://www.youtube.com/watch?v=dmSPvJxPm80

thevania 3y ago

when you look properly at the end of the video the root hash starts with $y$ implying its yescrypt more info here https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en... https://www.openwall.com/yescrypt/ https://www.openwall.com/yescrypt/ once you have the hash you have to use some rainbow tables if they exist for that hash function or bruteforce it the authors of yescrypt claim: "Technically, yescrypt is the most scalable password hashing scheme so far, providing near-optimal security from offline password cracking across the whole range from kilobytes to terabytes and beyond. " in any way, this is a local attack, someone / some software on your local machine would need to execute it so i am not overly stressed, password hashes leak all the time from all different sources yet, it does worry me because my AMD stock is dropping on value because of this today :D

CodesInChaos 3y ago
Rainbow tables are only applicable to unsalted hashes (or possibly to ones with tiny salts). They are so rarely applicable, that I wouldn't even bother mentioning them. On that list, NT is the only completely unsalted hash, plus DEScrypt and its variants might still be susceptible with its 12 bit salt. Like all decent password hashes, yescrypt is salted.
- deleted 3y ago
  [deleted]
nneonneo 3y ago
fwiw, yescrypt uses a salt so it will not be vulnerable to rainbow tables, and it is a slow hash so it won’t be that easy to bruteforce. A good strong password with a good hash function should remain secure even if the hash leaks.

barbito 3y ago

It's just an example. If you can leak kernel Memory you leak every process memory. So for example you can leak the content of a running browser

e12e 3y ago

> Whats the security implication of leaking the root hash? That you can try to crack the hash off-line with something like hashcat. For a random, salted, 22 character password (roughly log2(62^22)~130 bits of entropy, no rainbow tables because of the salt) - it might not be game over. On the other hand - if you can make an educated guess at the password - it's now trivial to check a few million variations without having to try to log in. As other's mentioned - reading arbitrary memory is probably worse (eg keyboard buffer, getting the plaintext password if a user logs in...).