libTiff exploit ?

[Archaemic]

I think I might be getting somewhere, but your script seems to be broken for me. I can't seem to get it to inject anything other than AAAAAAAA, and when I commented out the #PAD line, it just...broke. And I don't know Ruby.

E] Nevermind, I got it working. I just have to know, though: is inserting one byte over and over part of the underflow, or is that part of how you're injecting it? I want to inject a whole word, but instead I'm just getting one byte injected over and over.

[wololo]

Originally Posted by Archaemic

I think I might be getting somewhere, but your script seems to be broken for me. I can't seem to get it to inject anything other than AAAAAAAA, and when I commented out the #PAD line, it just...broke. And I don't know Ruby.

It's very basic, so you probably have to tweak it (a lot) in order to make something useful.
$code is supposed to contain an hexadecimal string
the line "size=25" can theoretically be replaced by size = n where n can be as high as, say, 250. That'll be the maximum number of bytes you code can contain.
You should probably not remove the padding line, it will have no effect if your code string is long enough anyway.

That being said, the first "useful" thing that gets overwritten by the underflow is unfortunately the array that creates the underflow itself. The code could probably be crafted to overwrite the array with "correct" values. Problem is, this array contains pointers (for which the value will probably be different every time you boot your psp...), so that becomes VERY complex...

good luck, I'll keep diggin on my side. PM me if you have other issues with my script

[Archaemic]

Haha, bad timing. See my edit. I can get it to cram a single byte all over memory, but not a whole word, and I just want to know if your script is capable of doing that (to your knowledge). If not, I'm not sure about the viability of this, but I'll keep plugging

(I have already gotten it to jump to 0x00000000...no, really! It read a null value and then jumped to it! Unfortunately, I seem to have very little control over where it's reading the value FROM)

[wololo]

in theory you should be able to have 250 bytes to work with, not only the same byte again and again, but if not, there might be a small bug in my script.

[Archaemic]

It only seems to inject the second to last byte of the code :/ Or, at least, primarily that. It writes a lot of other stuff all over RAM, but it's primarily the second to last byte of the code.

E] I've determined that it's the line that's marked "TODO improve" that determines which code is plastered all through memory...everything after that line just doesn't seem to do anything in terms of what's plastered.

E2] I've gone over the script, and I can't figure out why it was working before (with one byte, at least), but this is probably due to the code that triggers it being...rather complex. I've tried tinkering with it, to no avail. I think I may have to cut out the code and stick it into a simulator or something :|

[npt]

wololo / Archaemic,
I have a psp 3k which has 4.20 fw on it and I am more than willing to beta test if there is anything at all (anything - even if it's repetetive) that will help to turn this into something at all useful. Just thought I'd offer. : )

Impulse (aka npt)

[wololo]

@Archaemic : I'll try to update my code soon. Meanwhile, you can give a try to ruby, it's a very cool language !

@impulse : thanks.

However the chances of this bug being useful are getting slimer. I don't know that much about assembly so I might be wrong, but I think $ra cannot be used here, because we're inside an infinite loop (while loop), so we'll never actually return from any function call.
Now what can be changed would be some address for the next instruction, but these addresses are coded on 4 bytes, and because of the way the underflow is done, we can only overwrite 1 byte at a time. So if (by chance) we change the next instruction's address, we'll only be able to change the first byte of it. Which, thankfully, seems to be the most significant...

Next step is to update my code so that it can erase the dec_codetab array with values that make sense (not sure that's even doable), then see what gets modified next... if that's next instruction call, we can then hope that we're able to use it to execute around the pointer "bp" (defined in tiff decompression) which could contain some interesting stuff (i.e. : written by us). That is, assuming bp hasn't been erased by the underflow...

If the memory looks something like that, there's still hope. I'm not sure about the stack and bp, and I'll try to figure it out.

Stack ?
...
dec_codetab
...
tp
...
bp ?

[Archaemic]

I figured out what the script is doing, yes. It wasn't too hard to figure out the Ruby. Regardless, I haven't quite figured out how the TIFF manages to trigger the loop we're seeing. It looks like it should be possible to create a circular chain on codep->next values, but I'm having a hell of a time getting that working.

[wololo]

That circular chain is supposed to be the one in $code. If it doesn't work correctly in my script, then that's probably just a small bug that I'll try to fix.

in order for the loop to trigger, we have to create an initial chain like this:
max => max-1 => max-2 => ....258

which is easily done by putting our initial $code values (whatever we want, basically), then a code clear followed by 259,260,...max

then you create the loop by having 258 pointing to max
which is done by sending a CODE_CLEAR value, then max

well, that a rough theory, it might be off by a few subtleties, but you get the idea.
max cannot be higher than 511, because it is encoded on 9bits. So the loop chain cannot be longer than (511-258) bytes

[Archaemic]

The trick here is to keep the value in the next link in the chain from getting overwritten by the previous value. Right now I've got it writing an arbitrary halfword, so I'm making progress

(payload looks like this: 256, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 256, 265, 264, 263, 262, 261, 260, 259, 258, 259, 260, 261, 262, 263, 264, 265, and it writes 7 8 as the halfword...I'm sure this can be reduced, but I'm trying to get a whole word here )

E] After a lot more investigation, I'm glad to say that I am halfway to injecting arbitrary code because I can now maybe 50% of its executions get it to jump to an arbitrary memory address. However, I can't inject code because I don't have anywhere to store the code. Furthermore, I can confirm that the specific vector I was using is patched in 5.00. So I think I'm done here. I'll give information in private, but I am reluctant to post a working TIFF here.