Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jpeg's CVE-2018-11813 #242

Closed
pgajdos opened this issue Jun 12, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@pgajdos
Copy link

commented Jun 12, 2018

See https://nvd.nist.gov/vuln/detail/CVE-2018-11813 for details.

The testcase exhibits the bug for me with libjpeg-turbo 1.5.3.

@dcommander

This comment has been minimized.

Copy link
Member

commented Jun 12, 2018

Unless I miss my guess, this isn't really a security issue. It's just an annoyance. The malformed input file has a Targa header that specifies an image width of 57188 and an image height of 32772, but obviously the file is missing most of that data, since a normal 1.9-gigapixel Targa file should be about 5 GB in size rather than 6k. When the end of the input file is reached, rdtarga.c continues compressing pixels until it has compressed all 1.9 billion of them, but since it is ignoring the return value from getc(), most of those pixels have values of 255 (i.e. (unsigned char)EOF.) At no point does the program read beyond the end of the input file or read out of memory bounds, and since the issue only affects the cjpeg program and not the underlying library, I struggle to comprehend how it could be exploited.

That being said, I do agree that it should be fixed. Simply replacing getc() with read_byte() causes cjpeg to abort with the appropriate error message, but no data is written to the output file. I am investigating how to make it work more like the PPM reader, which will abort upon encountering an unexpected EOF in the input but will save the JPEG data compressed thus far.

dcommander added a commit that referenced this issue Jun 12, 2018

Fix CVE-2018-11813
Refer to change log for details.

Fixes #242
@dcommander

This comment has been minimized.

Copy link
Member

commented Jun 12, 2018

Upon further inspection, the issue whereby no data was written to the output only occurred when compressing a bottom-up TGA file, because such files are preloaded into memory by the reader. When compressing a top-down TGA file, replacing getc() with read_byte() causes the Targa reader to behave like the PPM reader. Fix pushed to both master (2.0) and 1.5.x branches.

@pgajdos

This comment has been minimized.

Copy link
Author

commented Jun 13, 2018

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.