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.
> 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.
As for /etc/shadow, it would be loaded any time someone attempts to login, and might even stick around in the page cache...
more info here https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en...
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
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.
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...).