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

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



Hi,

My current understanding of the problem (based on investigations on
latest master, but also valid for older versions):

The code_t string type is defined as a kind of chained list. Each entry
contains:

. a pointer to the next string entry
. a length field indicating the remaining length of the string

This length field includes the current entry.

. a value field containing the current string character
. the first character of the string

In the affected source code

> do {
>     *--tp = codep->value;
> } while ( (codep = codep->next) != NULL );

we read such a string and put the values into a buffer (in reverse order, but,
well, it doesn't matter).

Here we assume that the string always has the size it claims to have in its
length field.

But it's not the case with the reproducer. There is a list that claims to have
only one character but defines two, so we continue to read and write to the
buffer even if we are already OOB.

So now the question is: why is that happening ? Is it directly user input or is
coming from an earlier bug in the source code ?

Even if I can't reproduce the issue with the original reproducer, the
versions in Wheezy, Jessie and Stretch are likely to be affected because
the affected code is present.

I'm going to continue my investigations, try to prepare a poc for older
versions, prepare a patch for latest master and backport it to Wheezy
(+ Jessie & Stretch if needed).

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