3 ms·
I wonder if similar hacks apply to zlib and .png as well.
by est 13d ago
I wonder if similar hacks apply to zlib and .png as well.
- nneonneo 13d agoProbably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
- tacomagick 13d agoThe infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
- nneonneo 13d agoThe problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers. In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
- wmf 13d agoZip and PNG bombs have been around for a while: https://github.com/0x48piraj/gz-bomb https://github.com/0x48piraj/gz-bomb https://libpng.sourceforge.io/decompression_bombs.html https://libpng.sourceforge.io/decompression_bombs.html