libTiff exploit ?

[wololo]

I had a more precise look at the code today, and I think there is a fundamental difference between LZWDecode and LZWDecodeCompat. I've also reached a few conclusions, but I hope I'm not the only one in the world looking at that code, because I could make a mistake, and I'm lazy.
I believe something can be done with LZWDecodeCompat, but probably not with LZWDecode.

As it's been said, some structs are stored in a array that has supposedly 4096 entries (haven't checked the exact number yet).
entries 0 to 255 are initialized with default values
entries 256 and 257 are never initialized. This is what I used to make a file that crashed the lib, but this is NOT going to lead to an exploit.
entries 258 to 4096 are initialized once to NULL, but this part of the array is not cleaned correctly afterwards, when a CODE_CLEAR is received.
There is a way to write bad entries in 258 to 4096 and have the codep value point to one of them at another pass.
Now, a "bad entry" means an entry that is acceptable when being written, but that will trick the reading step at next pass.

Look at this code in LZWDecodeCompat:

op += codep->length, occ -= codep->length;
tp = op;
do {
    *--tp = codep->value;
} while( (codep = codep->next) != NULL);

you can compare it to LZWDecode:

len = codep->length;
tp = op + len;
do {
	int t;
	--tp;
	t = codep->value;
	codep = codep->next;
	*tp = t;
} while (codep && tp > op);

in LZWDecodeCompat, this part of the algorithm relies on the fact that we will have the same number of codep->next calls as codep->length.
in other words, if we can have codep->length equal to a small value, while having lots of calls to codep->next, a buffer underflow can be created in tp.

for example:
258 [length : 1, next : 259]
259[length : 1, next 260] -> if it were correct, this one should have a length of 0 and next=NULL
260[length: 1, next : 261] ...

everything relies on the fact that "next" is not NULL where it should be

In LZWDecode, however, there is also a check on tp's value against op, which prevents the underflow from happening.

so in order for a buffer underflow to happen :
- The TIFF file has to be in the old Aldus format (this can be done by reading LZWDecodeCompat and rewrite LZWEncode... boring but doable)
- The TIFF file has to be crafted in order to mess up "correctly" with entries 258 to 4096 (the whole point is to have no "NULL" in entries "next" attribute, and lie with the length of the first entry, ie probably entry 258), and then to redirect codep to the first entry. This should cause around 3800 bytes to be written between tp-3800 and tp, which is where the buffer underflow occurs.

I'm still not saying this will produce anything useful, and I'm definitely not saying I'll be working on it, this is far more complicated than what I initially imagined.

[Archaemic]

LZWDecodeCompat is CONDITIONALLY compiled into tif_lzw.o. It's not always there. Fortunately, I've been reading over the compiled code that triggered the crash, and have determined that it is this code right here:

if (codep->length > occ) {
				/*
				 * String is too long for decode buffer,
				 * locate portion that will fit, copy to
				 * the decode buffer, and setup restart
				 * logic for the next decoding call.
				 */
				sp->dec_codep = codep;
				do {
					codep = codep->next;
				} while (codep->length > occ);
				sp->dec_restart = occ;
				tp = op + occ;
				do  {
					*--tp = codep->value;
					codep = codep->next;
				}  while (--occ);
				break;
			}

With the bolded code being what crashes the PSP, as codep at that point has a bogus value. This code is only in LZWDecodeCompat, so it is compiled in!

Note that I was looking at decompiled 3.95 vsh/modules/paf.prx for this. I don't know what 4.20's version of this module looks like.

[jas0nuk]

Once again, libtiff proves highly insecure
Maybe MaTiAz will work on this when he's ported Sparta Exploit to the EUR and JPN Gripshift versions... ?

[wololo]

MaTiAz's recent success reduced a bit my motivation to work on this vulnerability, but it's fun to work on such things, so I'll let you know if I make any progress. Let's keep this thread alive if we find more stuff !

[MaxMouseDLL]

Originally Posted by wololo

MaTiAz's recent success reduced a bit my motivation to work on this vulnerability, but it's fun to work on such things, so I'll let you know if I make any progress. Let's keep this thread alive if we find more stuff !

Eggs - Basket comes to mind, multiple exploits would be nice. Also the plus side of LibTiff is it doesn't require the GripShift game.

If LibTiff could prove fruitfull (IE: kernel-mode hijack or something) it would be more popular than GripShift vuln.

[z7shaft]

Well it would be kind of popular but not more... why?
Well the Gripshift error happens even at 5.02 GEN (so up to the lastest firmware released) and if I'm not mistaken, wasn't this exploit patched in 4.21? So this would work only for people up to 4.05 in PSP2K, and people with 4.20 PSP3K from factory... And I don't think thats a lot of people because most of the users I know with PSP3K have updated to 5.00 for the new features, and also some PSP2K users with 88v3 MB have updated to 5.00...

[wololo]

Bad news so far.
I managed to create a tif file that creates a buffer underflow with this vulnerability. I could confirm it on cygwin.

Unfortunately on the PSP I just get an error message "corrupted data". My current guess is that I'm overwriting not the code but the data, so at some point the infinite loop ends (because I broke the "infinite" data) and a "regular" error is triggered.

Since this bug currently leads nowhere for the PSP, I'm not distributing the files.

The libtiff test suite includes a "old style" image that displays correctly on the PSP, so I could confirm LZWDecodeCompat is running on firmware 4.20.

Next step would be to understand what the RAM looks like when the image is decoded in the XMB, any help on that subject would be appreciated.
I could also create a homebrew that would load the image in the hope that it would give me some information on the RAM. Do we have a way to load tiff images with sony functions ?

[wololo]

Ha, better news today : rather than trying to create my own files, I decided to inject the bug into an existing file, which gave better results.

in the following link, you'll find :
- a file "original.tif" which is a correct tif file decoded with LZWDecodeCompat
- a file wololo.tif, which is the same file, but with an infinite loop added. This file writes the value "170" (hexadecimal "a") at the adress pointed by "tp", and makes it decrement infinitely (buffer underflow)
- a file inject.rb, the script that injects the loop code into the original file to create the new one.

The file "wololo.tif" consistently crashes my 4.20 psp.
http://wololo.net/files/libtiff_bufferunderflow.zip

Edit : here is the crash in psplink. No clue what this all means Apparently, there are 2 errors in 2 different threads. I'm guessing that the stuff that says "AAAAAAB0" is what the infinite loop wrote

host0:/> Exception - Address load/inst fetch
Thread ID - 0x05113261
Th Name   - ScePafJob
Module ID - 0x04784823
Mod Name  - scePaf_Module
EPC       - 0x09ACF394
Cause     - 0x90000010
BadVAddr  - 0xAAAAAAB0
Status    - 0x20088613
zr:0x00000000 at:0x2008FF00 v0:0x000000AA v1:0xAAAAAAAA
a0:0x088E9EC5 a1:0x088E9ED8 a2:0x00009FF8 a3:0x00000119
t0:0x00000009 t1:0x088E7E70 t2:0x088E9ED0 t3:0x088E9EE0
t4:0x088E61BB t5:0x00000004 t6:0x00001C8A t7:0x088FCD06
s0:0x088EA608 s1:0x088E4DE0 s2:0x09BC0000 s3:0x0000000A
Exception - Bus error (data)
s4:0x09BC0000 s5:0x088FCB90 s6:0x00000004 s7:0x088FCB90
Thread ID - 0x049D9515
t8:0x0000000A t9:0x000001FF k0:0x09FEDE00 k1:0x00000000
Th Name   - ScePafThread
gp:0x09BC8330 sp:0x09FED460 fp:0x00000600 ra:0x09ABC460
0x09ACF394: 0x5460FFFC '..`T' - bnezl      , 0x09ACF388
Module ID - 0x04784823
Mod Name  - scePaf_Module
EPC       - 0x09B203BC
Cause     - 0x1000001C
BadVAddr  - 0xAAAAAAB0
Status    - 0x20088613
zr:0x00000000 at:0x2008FF00 v0:0x5DE3A010 v1:0x5DE3A010
a0:0x00000000 a1:0x00000002 a2:0x088E4AC0 a3:0xBC400000
t0:0x88048384 t1:0x882FC000 t2:0x8824ECD8 t3:0x00000000
t4:0x09FFFB60 t5:0x00803E0C t6:0x09B6EAF4 t7:0x20088600
s0:0x000036E8 s1:0x088F9DF0 s2:0x088E4B9C s3:0x088D4E30
s4:0x088E4C90 s5:0x00000000 s6:0x00000000 s7:0x00000026
t8:0x88050000 t9:0x00000000 k0:0x09FFFE00 k1:0x00000000
gp:0x09BC8330 sp:0x09FFFC20 fp:0x088E4B78 ra:0x09B2038C
0x09B203BC: 0x8C450000 '..E.' - lw         , 0()

[Archaemic]

Well, um, that TIFF crashed Finder. Haha, oops, maybe I should tell Apple about this. I'll look into this more tomorrow when I'm more rested and my PSP is recharged (battery is dead right now).

[wololo]

damn, I played a little bit with PSPLink, and from the memory dumps it seems I'm overwriting dec_codetab itself...
Now this is becoming difficult...