[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat


> It looks like this buffer overflow is the consequence of an earlier buffer
> overflow in the GetNextCodeCompat macro:

Hum, that was not completely true. But I think I got it now.

The buggy sequence is:

1) Initialy oldcodep points to 0x632000001890.
   We get code 0x010c = 268, add it to the code table, print some stuff
   and read the next code.

2) The next code is 0x100, which is CLEAR_CODE, so we set free_entp to
   0x632000001820 (= sp->dec_codetab + CODE_FIRST).

   Then, we memset free_entp with a size of
   = (MAXCODE(BITS_MAX)+1024L)-258
   = (MAXCODE(9)+1024L)-258
   = ((1L<<(9))-1)+1024L-258 = 1277

   This means that everything between 0x632000001820 and 0x632000001D1D
   will be set to 0. Then we read the next code.

3) Next code is CLEAR_CODE, same as before, nothing changes.

4) Next code is 0x01d6. This is bad because it is too big for a first
   code. At this point we exit 0 without updating the decoder state.

5) Because we exit 0, TIFFReadScanline(in, buf, row, s) < 0 in
   tools/tiffcp.c is false and the whole process is repeated !

6) So, again, oldcodep initially points to 0x632000001890. BUT,
   remember, this area was set to 0 by 2) !

   So, well, we read the next code which is 0x010c and add it to the code
   table. This means that for our 0x010c code @codep, codep->next will
   point to the memset-ed area ! This means that codep->next->next == NULL.

7) Overflow, NULL pointer dereference, etc.

So, what is the solution ?

First, change

TIFFReadScanline(in, buf, row, s) < 0

in tools/tiffcp.c to

TIFFReadScanline(in, buf, row, s) <= 0

It is important to understand that 0 is also an error code here. Otherwise,
change error handling in tif_lzw to return negative numbers.

Then, there's maybe something to fix in tif_lzw, but I'm not quite sure
at the moment and I still have to check that.

Now that the issue is clear to me, I'll check the Wheezy code and try to
see why the issue isn't reproducible there.


             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

Attachment: signature.asc
Description: PGP signature

Reply to: