You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=313) [details] TIFF that underflows LZWDecodeCompat As described here: http://www.lan.st/showthread.php?t=1856&page=3 and reproduced here: https://bugs.edge.launchpad.net/bugs/380149 LZWDecodeCompat can be made to underflow with a crafted TIFF (attached).
Created an attachment (id=314) [details] protect against underflow This patch seems to protect the underflow, but has not been fully regression tested.
I have applied the suggested patch to tif_lzw.c in trunk and 3.9 branch. I cannot see any potential problems with the patch, though I'm not clear whether there may be other similar problems still in tif_lzw.c. Thanks!
Somewhat ironically, I had annoying problems with my system today and it turned out to be due to leaving wohoho.tif on the Desktop where it crashed nautilus!
It should be noted that this is a duplicate of http://bugzilla.maptools.org/show_bug.cgi?id=1985 My patch for that bug actually patches the root cause of the underflow instead of just breaking the infinite loop when it comes up.
Ah! I had assumed that was a different issue because all the error messages said "LZWDecode" instead "LZWDecodeCompat". Looking at line numbers, I see that the second hunk of the patch is in LZWDecodeCompat. (Perhaps adjust the error message at some point?) Thanks!
Yeah, those error messages were like that when I started. I thought about changing that in the patch, but thought it was better for a different patch. Either way, the patch attached to this bug will prevent the loop from stomping outside of its bounds, but it does not keep it from stomping all over its own memory. The underflow is (thankfully) only caused by malformed TIFFs, whereby the internal structure governing the loop says the next thing to be copied is itself. My patch prevents the structure from getting in the loop to begin with. I have additional research on this bug, if necessary. Documentation is kind of scarce, though, and most of it is up in my head. However, the reason it gets into the loop is because it processes character codes over 255 specially, and when it a CODE_CLEAR (telling the LZW decoding routine to reset the table) followed by something above CODE_CLEAR (generally something in the LZW table), that portion of the table is undefined. It is illegal to reference this, so my patch tells the routine to stop decoding, instead of having undefined behavior (which, in this case, results in an underflow, but with the patch attached to this bug, it stops the loop before it goes out of bounds, and then happily continues on).
FWIW, I'm planning to use the patch in bug #1985, and not this one, in Red Hat's libtiff packages. The earlier patch cures the problem AFAICT and provides much more desirable error handling behavior.
I have backed out the #2065 patch, and applied the #1985 patch in CVS head (libtiff4), but not in the 3.9 branch.