Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 234080 (CVE-2008-2327) - media-libs/tiff <3.8.2-r4 buffer underflow in LZW decoding (CVE-2008-2327)
Summary: media-libs/tiff <3.8.2-r4 buffer underflow in LZW decoding (CVE-2008-2327)
Alias: CVE-2008-2327
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: A2 [glsa]
Depends on:
Reported: 2008-08-06 12:15 UTC by Robert Buchholz (RETIRED)
Modified: 2020-04-09 19:04 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

tiff-3.8.2-CVE-2008-2327.patch (tiff-3.8.2-CVE-2008-2327.patch,807 bytes, patch)
2008-08-06 12:44 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff
tiff-3.8.2-bug1929.patch (tiff-3.8.2-bug1929.patch,1.32 KB, patch)
2008-08-06 12:44 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff
tiff-3.8.2-r4.ebuild (tiff-3.8.2-r4.ebuild,1.68 KB, patch)
2008-08-20 12:48 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Buchholz (RETIRED) gentoo-dev 2008-08-06 12:15:21 UTC
** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **

Drew Yao writes:
We have found a security issue in libTIFF's handling of LZW-encoded  
images.  The use of uninitialized data could lead to a buffer  
underflow and a crash or arbitrary code execution.

CVE-ID: CVE-2008-2327

Versions known to be affected:

This issue should remain embargoed until 8/25/2008.

Drew Yao of Apple Product Security

We have contacted the libTIFF maintainers about this issue.

A brief introduction to LZW decoding:

The LZW algorithm is based on a translation table, or string table,  
that maps strings of input characters into codes. The TIFF  
implementation uses variable-length codes, with a maximum code length  
of 12 bits
The string table is initialized to contain all possible single- 
character strings. There are 256 of them, numbered 0 through 255,  
since our characters are bytes.  There are also special codes:
#define CODE_CLEAR      256             /* code to clear string table */
#define CODE_EOI        257             /* end-of-information code */
#define CODE_FIRST      258             /* first free code entry */
As decoding continues, longer strings are added to the string table as  
linked lists of characters.  If the string table gets full(4096  
entries), there is a "Clear code" which signals to reinitialize the  
string table.


In LZWSetupDecode():
              sp->dec_codetab = (code_t*)_TIFFmalloc(CSIZE*sizeof  (code_t));

In LZWPreDecode():
       sp->dec_free_entp = sp->dec_codetab + CODE_FIRST;
       * Zero entries that are not yet filled in.  We do
       * this to guard against bogus input data that causes
       * us to index into undefined entries.  If you can
       * come up with a way to safely bounds-check input codes
       * while decoding then you can remove this operation.
      _TIFFmemset(sp->dec_free_entp, 0, (CSIZE-CODE_FIRST)*sizeof  (code_t));

In LZWDecodeCompat(), LZWDecode(), and LZWDecodeVector(), when a  
CODE_CLEAR code is received, the string table does not get re-zeroed,  
leading to uninitialized data in the table being used, if the next  
code after the CODE_CLEAR is > CODE_FIRST.

For example in LZWDecodeCompat():
      while (occ > 0) {
              NextCode(tif, sp, bp, code, GetNextCodeCompat);
              if (code == CODE_EOI)
              if (code == CODE_CLEAR) {
                      free_entp = sp->dec_codetab +  CODE_FIRST;          <-- free_entp points to the first free entry  
after the constant entries.
                      nbits = BITS_MIN;
                      nbitsmask = MAXCODE(BITS_MIN);
                      maxcodep = sp->dec_codetab + nbitsmask;
                      NextCode(tif, sp, bp, code,  GetNextCodeCompat);     <-- get the next code.   The implementation  
expects it to be < CODE_FIRST, but that might not be true in a  
malicious file.
                      if (code == CODE_EOI)
                      *op++ = code, occ--;
                      oldcodep = sp->dec_codetab + code;
              codep = sp->dec_codetab + code;              <--codep  
points into uninitialized data

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


A simple fix is to zero out the whole string table starting at  
CODE_FIRST whenever a CODE_CLEAR is received.
The attached patch against 3.8.2 does this.

I have tested this fix to properly display a bunch of valid files, and  
not crash after heavy fuzzing.
Comment 1 Robert Buchholz (RETIRED) gentoo-dev 2008-08-06 12:39:06 UTC
Drew also informed us about the following issue:
Comment 2 Robert Buchholz (RETIRED) gentoo-dev 2008-08-06 12:44:31 UTC
Created attachment 162354 [details, diff]
Comment 3 Robert Buchholz (RETIRED) gentoo-dev 2008-08-06 12:44:51 UTC
Created attachment 162356 [details, diff]
Comment 4 Robert Buchholz (RETIRED) gentoo-dev 2008-08-20 12:48:15 UTC
We have no upstream comment on either of the two patches, and probably won't have until after the embargo timeline. I'll attach an ebuild applying the existing patches, and we can update them later if upstream decides otherwise.
Comment 5 Robert Buchholz (RETIRED) gentoo-dev 2008-08-20 12:48:34 UTC
Created attachment 163378 [details, diff]
Comment 6 Robert Buchholz (RETIRED) gentoo-dev 2008-08-20 12:49:25 UTC
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug.
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"

CC'ing current Liaisons:
   alpha : yoswink, armin76
   amd64 : keytoaster, tester
    hppa : jer
     ppc : dertobi123
   ppc64 : corsair
   sparc : fmccor
     x86 : maekke, armin76
Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2008-08-20 15:47:43 UTC
Comment 8 Markus Meier gentoo-dev 2008-08-20 17:50:38 UTC
looks good on amd64/x86.
Comment 9 Markus Rothe (RETIRED) gentoo-dev 2008-08-20 22:39:48 UTC
looks good on ppc64
Comment 10 Jose Luis Rivero (yoswink) (RETIRED) gentoo-dev 2008-08-20 23:24:44 UTC
alpha is ok
Comment 11 Robert Buchholz (RETIRED) gentoo-dev 2008-08-26 14:32:05 UTC
now public via
Comment 12 Robert Buchholz (RETIRED) gentoo-dev 2008-08-26 14:53:44 UTC
I combined both patches into one because it was decided to combine both issues (Drew Yao and the upstream bug) into the CVE. Committed the ebuild to the tree with the gathered keywords, still to do:

Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Already stabled : "alpha amd64 hppa ppc64 x86"
Missing keywords: "arm ia64 m68k ppc s390 sh sparc"
Comment 13 Raúl Porcel (RETIRED) gentoo-dev 2008-08-26 15:04:09 UTC
ia64/sparc stable
Comment 14 Tobias Scherbaum (RETIRED) gentoo-dev 2008-08-30 11:30:45 UTC
ppc stable
Comment 15 Tobias Heinlein (RETIRED) gentoo-dev 2008-09-02 17:01:59 UTC
GLSA request filed.
Comment 16 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-09-08 18:01:22 UTC
GLSA 200809-07