Bug 2065 - LZWDecodeCompat buffer underflow
: LZWDecodeCompat buffer underflow
Status: RESOLVED FIXED
: libtiff
default
: unspecified
: All All
: P2 normal
: ---
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-06-22 00:03 by
Modified: 2009-06-30 04:19 (History)


Attachments
TIFF that underflows LZWDecodeCompat (209.32 KB, application/octet-stream)
2009-06-22 00:03, Kees Cook
Details
protect against underflow (680 bytes, patch)
2009-06-22 00:04, Kees Cook
Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-06-22 00:03:29
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).
------- Comment #1 From 2009-06-22 00:04:56 -------
Created an attachment (id=314) [details]
protect against underflow

This patch seems to protect the underflow, but has not been fully regression
tested.
------- Comment #2 From 2009-06-22 04:58:26 -------
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!
------- Comment #3 From 2009-06-22 13:20:31 -------
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!
------- Comment #4 From 2009-06-23 21:12:22 -------
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.
------- Comment #5 From 2009-06-23 22:03:30 -------
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!
------- Comment #6 From 2009-06-23 23:49:06 -------
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).
------- Comment #7 From 2009-06-29 16:21:37 -------
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.
------- Comment #8 From 2009-06-30 04:19:06 -------
I have backed out the #2065 patch, and applied the #1985 patch in CVS head
(libtiff4), but not in the 3.9 branch.