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
[CVE-2016-6132]: A read out-of-bands was found in the parsing of TGA files #247
Comments
|
I can confirm the issue using valgrind. The reason of the bug is that the TARGA file is corrupt; its header reports a size of 1x2055 pixels, so 2055 bytes are to be read, but it only contains 56 bytes of image data. It seems to me that checking that the return value of the respective gdGetBuf is equal to image_block_size, and gracefully error'ing out otherwise is the best solution. The same check would have to be done for RLE TARGA files, and maybe for other file types as well. |
|
agreed on both. want to put together the PR ? :) |
|
I'll give it try, but it may take some days (rather busy otherwise, currently). |
|
@cmb69 @pierrejoye @vapier Folks could you review the changes in PR #250 ? |
|
It looks like QuickFuzz can still find a read out-of-bound. The new test case is here. We recently added a new feature to our tool, to dump the internal structure of the corrupted file causing a crash in the .val file (hopefully it can help!). Maybe this patch wasn't complete? |
|
@gaa-cifasis Have you tested QuickFuzz with #251 ? |
|
This TGA is not (recognized as being) RLE'd, so #251 doesn't apply. Anyway, I can reproduce the issue with valgrind, so re-opening. |
|
The problem is https://github.com/libgd/libgd/blob/gd-2.2.2/src/gd_tga.c#L102. In this case Also we probably need an else block to gracefully fail for unsupported tga->bits and tga->alphabits. |
|
I have a fix, but that breaks tests/tga/bug00084, because bug00084.tga has 8bpp, what is not supposed to be supported anyway. I'll see to it. |
Well, not really. I simply screwed up the patch. |
|
Fixed with commit 10ef1dc; closing. |
|
@cmb69 did you merged/cherry-picked it to GD-2.2? |
|
The build fails, so I've reverted the commit for now. I'll have to take a closer look. |
|
@cmb69 Does it fail everywhere or just Mac OS X? (The failure on Macs is orthogonal to this issue...) |
|
No, it did fail everywhere due to a typo in Makemodule.am. I've fixed that with commit cb1a0b7. Now the Linux checks work fine, but the OS X checks seem to stall (https://travis-ci.org/libgd/libgd/builds/144312731). :-/ |
|
Ah, apparently Travis was just busy! Eventually, all checks succeeded, and so I cherry-picked into GD-2.2. @gaa-cifasis Thanks for the report(s)! If you find further bugs, please file new issues. Actually, the first and the second where not really related, and it's easier for us to separate concerns. |
|
JFTR CVE for #248 has already been requested by Debian Security Team. |
|
Second issue is CVE-2016-6214 |
Hi,
A read out-of-bands was found in the parsing of TGA files using the last revision of libgd (a6a0e7f). Find attached a small sample (it is a tga, not a really a txt) to reproduce it. The ASAN report is here:
(it is not related with bug 00084, i just re-used the test case to read an arbitrary TGA file)
This issue was found using QuickFuzz.
Regards,
Gustavo.
The text was updated successfully, but these errors were encountered: