#592 Non-malicious JPEG file fails with "Unreasonable dimensions"

[Mattias Wadman]

Hello!

Im working on transcoding system that recently received image files that are failing with "Unreasonable dimensions". Im quite sure the files are not created to be malicious in any way.

Not sure if im allowed to distribute the failing files but i can reproduce the error with these commands:

ffmpeg -f lavfi -i color=color=black@0.0:size=640x640,format=rgba -frames:v 1 unreasonable.bmp
cjpeg -block 16 -optimize -outfile unreasonable.jpg unreasonable.bmp
gm convert -debug All unreasonable.jpg unreasonable.jpg.bmp

[Mattias Wadman]

It seems to fail the uncomrpessed file can't the more than 512 times the input file size check

[Bob Friesenhahn]

On Tue, 12 Feb 2019, Mattias Wadman wrote:

It seems to fail the uncomrpessed file can't the more than 512 times the input file size

What is the size (in bytes) of "unreasonable.jpg" and the reported
effective compression ratio? I assume that the compression ratio
should be included in the traces.

Bob

[Mattias Wadman]

Hi again!

-rw-r--r--  1 wader  staff  1638454 Feb 12 11:12 unreasonable.bmp
-rw-r--r--  1 wader  staff      884 Feb 12 11:12 unreasonable.jpg

[Mattias Wadman]

Or i guess in the code it will be 640x640*4 / 884 = 1 853,3936651584 which is > 512

[Mattias Wadman]

But im not sure what the most proper solution is. Incerase 512? in our case we just removed the check and rely on resource limits instead

[Bob Friesenhahn]

On Tue, 12 Feb 2019, Mattias Wadman wrote:

But im not sure what the most proper solution is. Incerase 512? in
our case we just removed the check and rely on resource limits
instead

A possibility is to only apply this type of test when the pixel
dimensions are sufficiently large to be of concern. It still does not
avoid the reality that it is possible to create an incredibly small
JPEG with a very high compression ratio which can decode to very large
dimensions such as 60000x60000. It is also possible to create JPEG
files with reasonable dimensions which will take hours or days to
decode.

Fuzz testing (to find weaknesses) subjects the software to both memory
consumption and time constraints. There is limited control once the
JPEG decoder has started decoding.

Most GraphicsMagick users will not apply any resource limits and
simply trust that the software will reject bogus files.

Bob

[Mattias Wadman]

Ok I see. I don't have strong opinion really as we can patch our version. But i wanted to file a bug just to let people know that valid non-malicious images can fail.

Thanks for sucha fast response and thanks for working on graphicsmagick

[Bob Friesenhahn]

What is the origin of the 'cjpeg' you are using which supports the '-block 16' option?

[Mattias Wadman]

It's part of the libjpeg distriution https://www.ijg.org/

[Bob Friesenhahn]

This problem is fixed by Mercurial changeset 15898:f756b4df2b14. Testing showed that it was possible to achieve JPEG compression ratios as high as 2400 so we allow up to 2500. Unfortunately, the value of the compression ratio check is diminished by needing to allow such high ratios.

[Mattias Wadman]

Ok seems reasonabe ;) thanks for looking into this!