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

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



Hi,

> 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
     CSIZE - CODE_FIRST
   = (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.

Cheers,
 Hugo

-- 
             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: