libTiff exploit ?

[Jachra]

Originally Posted by wololo

That's my concern. The exploit was found on 8/26, and the 4.20 firmware which ships with psp3000 was released in october...
Chances are high that firmware 4.20 already has a patch for this issue, unfortunately there is no "proof of concept" file available publicly to test...

Maybe, but we can check which version of libtiff is in the original firmware's. Afterwards we can determine on which version of the original firmware this exploit might work.

[wololo]

More detailed information:

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.

tif_lzw.c

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)
                      break;
              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)
                              break;
                      *op++ = code, occ--;
                      oldcodep = sp->dec_codetab + code;
                      continue;
              }
              codep = sp->dec_codetab + code;              <--codep  
points into uninitialized data
...

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


[...]

I believe I've found a bug in libtiff and I'd like to ask for some assistance in
verifying both what I believe to be the bug and the fix. Please bare with me as
I attempt to describe what I believe to be the issue.

Turn your eyes to libtiff/tiff_lzw.c. LZWCodecState::dec_codetab is an array of
code_t structs where the elements are indexed by special LZW codes in the file.
The order of the elements goes something like:

0-255: pre-loaded LZW codes
256: CODE_CLEAR
257: CODE_EOI
258...: free code spaces

Each code_t contains a pointer to another code_t so the structure ends up being
akin to a linked-list. The pre-loaded codes are initialized at the end of
LZWSetupDecode() and the free code elements at the end of LZWPreDecode().
However, the CODE_CLEAR and CODE_EOI entries do not contain valid structures
because their codes have special meanings.

It is possible to create a corrupt tiff image where there are two clear codes in
a row. When they are read in at LZWSetupDecode() and LZWDecodeCompat(), it
causes oldcodep to point to the CODE_CLEAR element in the
LZWCodecState::dec_codetab array. Because the pointer in this element is never
initialized, it can result in a seg fault (or worse) when the link list is
traversed at a later point.

I have reproduced this bug on both Linux and Windows and it appears to be
present in the latest versions of libtiff.

I apologize for not having an easily reproducible seg fault at this time. I can
try to create this if it will help. I have a copy of a bad tiff image which
will reproduce this bug, but I'm not sure how to pass this on to the libtiff
team at the moment.

I believe the best fix is twofold:
1) Ensure that the table entry for the clear code is zeroed out.
2) Correctly handle the case where two clear codes are found together.

Here is a patch which will do so:
--- tiff-4.0.0beta2/libtiff/tif_lzw.c.bak 2008-08-04 12:01:34.532857000 -0700
+++ tiff-4.0.0beta2/libtiff/tif_lzw.c 2008-08-04 12:04:01.048197000 -0700
@@ -244,6 +244,12 @@
sp->dec_codetab[code].length = 1;
sp->dec_codetab[code].next = NULL;
} while (code--);
+ /*
+ * Zero-out the unused entries
+ */
+ _TIFFmemset(&sp->dec_codetab[CODE_CLEAR], 0,
+ (CODE_FIRST-CODE_CLEAR)*sizeof (code_t));
+
}
return (1);
}
@@ -429,6 +435,12 @@
NextCode(tif, sp, bp, code, GetNextCode);
if (code == CODE_EOI)
break;
+ if (code == CODE_CLEAR) {
+ TIFFErrorExt(tif->tif_clientdata, tif->tif_name,
+ "LZWDecode: Corrupted LZW table at scanline %d",
+ tif->tif_row);
+ return (0);
+ }
*op++ = (char)code, occ--;
oldcodep = sp->dec_codetab + code;
continue;
@@ -633,6 +645,12 @@
NextCode(tif, sp, bp, code, GetNextCodeCompat);
if (code == CODE_EOI)
break;
+ if (code == CODE_CLEAR) {
+ TIFFErrorExt(tif->tif_clientdata, tif->tif_name,
+ "LZWDecode: Corrupted LZW table at scanline %d",
+ tif->tif_row);
+ return (0);
+ }
*op++ = code, occ--;
oldcodep = sp->dec_codetab + code;
continue;

sources:
http://bugs.gentoo.org/show_bug.cgi?id=234080
http://bugzilla.maptools.org/show_bug.cgi?id=1929

[wololo]

I managed to create somes tif files that crash my PSP 3000 on OFW 4.20
My tests on a Phat with CFW 5.00 m33-4 tend to show that the vulnerability has been fixed in firmware 5.00

Here are the files:
http://wololo.net/files/libtiffcrash.zip

There are 2 files because it seems to increase the probability of crash. But 1 should actually be enough.
put the files in PSP/PHOTO, and try to view either the thumbnails or the pictures themselves, it should crash the PSP.
The bug seems pretty random (depends on the state of the RAM, I guess), so you might have to reboot the PSP a few times and try again.

video:

YouTube - Libtiff Crash - PSP 3000 - OFW 4.20

I have lots of things to discuss on the subject, but I don't have enough time right now. Thing is, I pretty much reached the limits of my knowledge here, but if somebody have a clue on how such a crash could be used, please contact me if you want information on how I created the files. This is a very simple modification of LZWEncode in tif_lzw.c

Again, this does NOT seem to work on 5.00, only on 4.20

[victorprosa]

As soon as a lot of 3000 users are still in 4.20 (like me) or 4.21, i think that this BUG deserves a good exploration...

[wololo]

According to some tests done by people on a japanese blog, it seems version 4.21 is patched, so this is 4.20 only :/

I could confirm the second statement (two CODE_CLEAR values in a row cause a crash), but I'm very doubtful about the first one (possibility of a buffer underflow), because I believe the following statement :

codep = sp->dec_codetab + code;              <--codep  points into uninitialized data

is incorrect.
The variable that can have problems is oldcodep, not codep.
And I am not sure if oldcodep can be really used

Finally, the people who reported bugs say they have files that crash on linux and windows. The files I created only seem to crash the PSP.
On cygwin (with unpatched 3.8.2, obviously), it just gives me an error message "Bogus encoding" and stops decompressing the file.

[npt]

I verified on my 3000 w/ 4.20 fw that this does indeed lockup / crash the PSP consistently. The first time I loaded the Tiffs, when I got into pictures and then loaded the first, I got a weird streak of color across the screen and it froze. Any attempts since the PSP freezes as soon as I see the thumbnails.

I also verified this DOES NOT happen on a 2000 w/ 5.00 m33-4.

Do you think this could possibly lead to code execution?

Regards,

Impulse / npt

[Archaemic]

I remember this...I experimented with this when it was first announced. I was never able to get my PSP to crash, though, so I don't know what I was doing wrong. I think I still have some files lying around that were what I was testing with, but I gave up after I was unable to crash anything. I guess this merits some further looking into.

I know I PMed FreePlay about this back when the vulnerability was first announced, but I guess he never looked into it.

E] The crash appears to be it trying to read from a bogus memory address. I am unsure of where the memory address comes from, but I can tell you that the value it loads (if successful) is compared against another value and overwritten in the next instruction. Not very useful, it seems. Still, there may be more to this than I'm seeing.

[wololo]

Originally Posted by Archaemic

E] The crash appears to be it trying to read from a bogus memory address. I am unsure of where the memory address comes from, but I can tell you that the value it loads (if successful) is compared against another value and overwritten in the next instruction. Not very useful, it seems. Still, there may be more to this than I'm seeing.

I'm afraid you're correct. I'll try to work on it a little bit more in the weeks to come, because the bug reports mention a buffer underflow, but the more I look at the code, the more I think the bug report is mistaken.
I'd be very happy not to be the only one looking at that though, just to be sure

[rebman]

Joined to help, I am from PSP-Hacks.

Tried this on my Slim 2000 that came with OFW 4.01 and am confirming that it successfully crashes.

[ffsapher]

psp slim on 4.05

http://pl.youtube.com/watch?v=cv4hnx35unA