forums.ps2dev.org

[BitShiftLeft]

Hello All,

I'm wondering if the following user agent string gives us a little information :- User-Agent: PSPUpdate-agent/1.0.0 libhttp/1.0.0

Is this a SCEI internally developed HTTP library or one that is nabbed from the web?

Hick.org has a library with a suspiciously similar name :-
http://www.hick.org/code/skape/libhttp/libhttp-1.0.0.tar.gz

Of course this could just be a coincidence, but having worked with Sony on a web connected device a while back, I can tell you that shortcuts were made by the developers in Tokyo using opensource or public domain code to save time and quickly fix a requirement.

I'm going to try to do some comparisons tonight, if this is the same code, then maybe the hick code should be examined a bit more closely to see if there is anything that can be exploited, maybe this *could* be a potential way to overflow the device as the firmware update infrastucture can be easily spoofed in the home/lab.

Of course sony firmware would need to be decrypted and checksummed before execution, but I'm thinking that maybe we can overflow *before* that point using problems in the libhttp code.

Of course these are all big "ifs" and someone might have investigated this already.

Another tact I was thinking about that if they did use the hick libhttp code and it was covered by the GPL then asking them for a tarball of source modifications to any GPL'd code could be another angle, but unfortunatly libhttp doesnt seem to be covered by the GPL :(

Maybe this is old news and has been ruled out, if it is, tell me to shut up and I'll go back to lurk mode ;)

[pixel]

Hick's libhttp is quite bullet proof... It does some intelligent reading by realloc()ing a buffer on demand.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[BitShiftLeft]

Do we think they are using that then?

[pixel]

No idea. You could still give a try with "let's flood the psp with fake HTTP answers", but, well, they would have taken great care not letting any overflow bug here, since it's quite a sensitive point.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[Yoorah]

About the open-source stuff -- apparently, Sony used parts of NetBSD for the PSP's "communications functions". A link to the NetBSD license is found in the user's manual (http://www.scei.co.jp/psp-license/pspnet.txt).
_________________
If at first you don't succeed, skydiving is not for you.

[Pollux]

Hi people, I had a quick look at the libhttp code.

It is definitely not free of bugs (although, as pixel mentioned, they did pay a little attention to security issues, and excessively long URLs won't allow exploits). I have not finished reading the source code, but I have found two bugs for now :

• one that should not be exploitable, it just makes libhttp not as fool-proof as Hick wanted, and it would require rather specific user code from Sony to be usable
  
• one that would at least allow us to retrieve uninitialized data from the RAM, depending on Sony's code : if the browser tries to send large POST forms (that could be made thanks to JavaScript, although I don't know if the browser has a built-in limit for these kinds of stuff), then there is the following bug :
  
  • the browser has successfully allocated POST data, and is going to call libhttp to add the POST data to the HTTP request
    
  • if there is not enough free RAM for libhttp to make an extra copy, then there is a bug in libhttp that will leave the POST content length intact (i.e. libhttp will still try to send the original content length, even though it doesn't remember the actual content)
    
  • yet if at the time the browser wants to send the HTTP request there is now enough free RAM to make an extra copy, then libhttp will send the POST request with uninitialized data instead of the original POST content
  
  Determining the right length for the POST data can easily be done through trial-and-error (it can even be automated thanks again to JavaScript).
  But the problem is that in order for this to be exploitable, the browser code has to free some RAM between the time when it adds the POST content, and the time when it asks libhttp to make the request (e.g. freeing the buffer containing the original POST request). Thus I can't tell whether this will work or not, it really depends on Sony's code.

That's not going to be a major breakthrough, but it may allow us to dump RAM, and get a better understanding of the internal layout of PSP memory (e.g. learn about the heap structure to be able to exploit buffer overflows, or if we're very lucky dump actual code that could be reverse-engineered for exploits -- although I don't really believe in the latter, given that this uninitialized data will only come from the actual heap). Plus, if we can find this kind of bug in only 1000 lines of code that's supposed to be fairly secure (there are really tons of sanity checks, I haven't seen any buffer overflow, *unsigned* integers are used everywhere, etc...), then it's rather promising for the future of PSP hacking =)


I don't have a PSP, but it would be interesting to try and see what happens when you ask for large POST requests (plus, it might uncover more serious flaws in Sony's code), which might be exploitable -- contrarily to large GET requests (which are blocked by Sony's browser). If you would like to test it on your own PSP and want me to write a small HTML page for this purpose, just ask :)

[DBG]

Pollux, I would like to explore further into your ideas. Whenever you have the code ready, I'll check it out (you also gave me some ideas of my own to try, and hopefully they will turn out better than my previous attempts at cracking this nut).

[Pollux]

Honestly don't expect this exploit to work, there are large chances that it will fail ; I do think it would be worth trying though.


I don't know if the built-in browser supports getElementById() or CSS, or if it's gonna be sluggish for large input sizes, but have a look at this :

[Pollux]

And by the way, anybody know if file upload works in the browser too ?

[tbirdsaw]

I tried getting file-upload to work... It didn't work. I used W3C's Code Validator as a test upload site. Probably not the best thing to use as a test, but it's all I could get at a short notice.
http://validator.w3.org/

It displays the Browse button with some Japanese Characters. When I click on it, the browser seems to lock up.

[tbirdsaw]

Testing your html, here's what I found:


If I submit 1024KB quickly, it seems to submit fairly quickly.

After 54 times though, it slows way down. It takes several seconds for it to post. Pausing for several seconds, and then continuing seems to clear a little memory, as it will post quickly once, then go back to taking several seconds to post.

Waiting a minute or so allows me to post 4 quickly, then it goes back to being sluggish.

I changed the size to 11059.2 and did it (surprisingly) 14 times before it started getting sluggish.

I am not sure if this is truely the PSP or possibly my webserver doing some kind of limiting (Stock FC1 Apache), but it's definitely overloading something.

[Pollux]

Thanks for trying :) When you submit several times you might be hitting a limitation of the Javascript engine's garbage collector... It would be best to try to get the highest amount of memory you can allocate in just one run from a freshly rebooted browser (or maybe that's your 11059.2kb?)

[tbirdsaw]

No... my 11059.2 is from me taking (1024 * 54) / 5 and putting that in. It's nothing special... I'll try the full size and see what happens.