4 ms·

Can someone ELI5 the severity of this over the whole internet? What breaks/what not

flatiron 4y ago
If you don’t use that library then nothing. If you do and you hash my crafted binary I probably could crash it.
Ayesh 4y ago
SHA3 is relatively infrequent compared to sha1/2 and md5. SHA3 also has a few variants, and I don't know for sure if this vulnerability is present in all variants. The vulnerability is only present in the reference implementation. So it's unlikely that other implementations (rush as Rust or Go) are vulnerable. I tested with the latest released and master branches of PHP, both of which segfaulted for the code samples mentioned in the article. The article says Python is also vulnerable.this is because both of the languages apparently use the reference implementation. Ethereum uses SHA3 quite extensively, but I doubt it's vulnerable post migration from PoW, let alone it's unlikely that they use the vulnerable implementation/variant.
capableweb 4y ago
Most people limit the amount of input that gets passed to whatever is doing the hashing (SHA-3 in this case) to some amount of bytes that are way less than this issue requires. Most web servers default to a 50MB limit or something like that, I think, not many things accept by default the size required for this exploit. Most cases would involve services that accept large untrusted files from users.
csande17 4y ago
The full advisory is linked at https://github.com/XKCP/XKCP/security/advisories/GHSA-6w4m-2xhg-2658 https://github.com/XKCP/XKCP/security/advisories/GHSA-6w4m-2.... In order for an application to be vulnerable, it must: 1. Break the file into multiple chunks and pass them to SHA-3 individually. 2. Make one of those chunks larger than 4 GB in size. (This requires using 4 GB of memory.) This is kind of an unlikely thing for an application to do. If you're breaking the file into chunks, usually you'd use smaller chunks. (And if your server is limited to less than 4 GB of RAM, you might not be able to allocate enough memory to trigger the vulnerability in any case.) But it could be exploitable in some really weird or poorly written application somewhere.
- fulafel 4y ago
  Nitpick: it requires using 4 GB of address space, not necessarily physical memory - the app might be eg memory mapping the file. (mmap() can be reasonably used for streaming usecases like this provided you use madvise() hints on whether you want the data kept resident after use, probably non unix platforms have similar apis)
  - csande17 4y ago
    Right, mmap() lets you get a big buffer without actually using that much physical memory. Good catch! I still think it's unlikely for an app to be vulnerable to this but having less than 4 GB of RAM isn't an absolute defense. Having a 32-bit address space probably is, though, if you're running on old or embedded hardware.

If you don’t use that library then nothing. If you do and you hash my crafted binary I probably could crash it.

SHA3 is relatively infrequent compared to sha1/2 and md5. SHA3 also has a few variants, and I don't know for sure if this vulnerability is present in all variants. The vulnerability is only present in the reference implementation. So it's unlikely that other implementations (rush as Rust or Go) are vulnerable. I tested with the latest released and master branches of PHP, both of which segfaulted for the code samples mentioned in the article. The article says Python is also vulnerable.this is because both of the languages apparently use the reference implementation. Ethereum uses SHA3 quite extensively, but I doubt it's vulnerable post migration from PoW, let alone it's unlikely that they use the vulnerable implementation/variant.

capableweb 4y ago

Most people limit the amount of input that gets passed to whatever is doing the hashing (SHA-3 in this case) to some amount of bytes that are way less than this issue requires. Most web servers default to a 50MB limit or something like that, I think, not many things accept by default the size required for this exploit. Most cases would involve services that accept large untrusted files from users.

csande17 4y ago

The full advisory is linked at https://github.com/XKCP/XKCP/security/advisories/GHSA-6w4m-2xhg-2658 https://github.com/XKCP/XKCP/security/advisories/GHSA-6w4m-2.... In order for an application to be vulnerable, it must: 1. Break the file into multiple chunks and pass them to SHA-3 individually. 2. Make one of those chunks larger than 4 GB in size. (This requires using 4 GB of memory.) This is kind of an unlikely thing for an application to do. If you're breaking the file into chunks, usually you'd use smaller chunks. (And if your server is limited to less than 4 GB of RAM, you might not be able to allocate enough memory to trigger the vulnerability in any case.) But it could be exploitable in some really weird or poorly written application somewhere.

fulafel 4y ago
Nitpick: it requires using 4 GB of address space, not necessarily physical memory - the app might be eg memory mapping the file. (mmap() can be reasonably used for streaming usecases like this provided you use madvise() hints on whether you want the data kept resident after use, probably non unix platforms have similar apis)
- csande17 4y ago
  Right, mmap() lets you get a big buffer without actually using that much physical memory. Good catch! I still think it's unlikely for an app to be vulnerable to this but having less than 4 GB of RAM isn't an absolute defense. Having a 32-bit address space probably is, though, if you're running on old or embedded hardware.