3 ms·
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
by 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 agoNitpick: 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 agoRight, 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.