Bugs

Unknown / unpatched

SnagFilms

A possible exploit has been found in the SnagFilms app in the PSStore app.

Arbitrary code execution in memory has been demonstrated, although so far the system will throw an exception in the programs memory before the payload finishes loading.

If you craft a small enough payload and/or a payload that load's without causing an exception in program memory you can most likely get code execution working.

http://i.imgur.com/5OrSFCa.jpg

(BattleCars Exploit-Rocket League)

Buffer Overflow- [Current system software, Most recent version of application(SYSSW 2.57)/(Rocket League 1.03)]

First block all requests from:https://patch103-dot-psyonix-rl.appspot.com/

When you launch Rocket League it gets a stub file from: http://psyonix-rl-529970.c.cdn77.org/BC2/versions/103/config/BattleCars_Prod/client.bin

You can redirect that to load a huge file and/or a specifly crafted payload instead of the stub. If you use the proper file, it doesn't need to be that large, the example below is under 9mb.

Your file will be loaded into memory, when the file is large enough/a game is played and/or you wait enough time you can consistently cause a buffer overflow and the application will crash.

Depending on how you craft your payload, you may or may not have to do any of that get it working. There are no checks performed at all on file size, content, ect.

Staying on the start screen for long enough can also trigger it. If your payload isn't created properly it will take much longer to execute.

If you are having problems getting this working, you can use the example file, causing an almost instant buffer overflow upon launch of the application.

http://sceecatalogs.vidzone.tv/469/vidzone_469_US.db.psarc

If your payload is crafted properly, you should be able to get it working withing 10-20 seconds of launching the application . A carefully crafted file may be able to exploit this or similar issues to gain code execution, among other things. It may also be possible to alter gameplay via similar methods.

No payload will be provided at the moment because this is very experimental.

VidNow (TCP Buffer Overflow)

A possible exploit has been found in VidNow app from the PSStore App.

PATCHED: Sony has hotfixed this exploit via content hashing the file while in transit. Some people have managed to reverse the hotfix but the method is not known - the PS4 checks the content. hash HTTP header from the HMAC header.

When you launch Vidnow for the first time it gets http://sceecatalogs.vidzone.tv/386/vidzone_386_US.db.psarc. This file is 5mb. This file loads into a 60k tcp buffer. No checks are done at all on the files size/hash/contents. Therefore, it is possible to redirect Vidnow to load a substitute file. When vidnow is redirected to load a large enough file the TCP Window buffer is overrun,somewhere between byte 34,125,000 and 35,000,000 of the substitute file. Despite the buffer overflow and crash, the substitute data is still transmitted and the application only throws the exception when another tcp packet is sent. As a result, the application crashes and the console locks up for a minute. Directly before the console resumes normal operations after the crash, an unusually large number of tcp (RST) packets are sent. While no exploit that makes use of this crash is currently available, a carefully crafted file may be able to exploit this or similar issues to gain code execution, among other things.

Crash Timeline

17:17:39.899984000 Request
17:17:40.000655000 Request
17:17:40 (System locks up) Crash
17:17:44.957274000 Response
17:17:48.500481000 Response
17:17:48.500567000 Response
17:17:50.356427000 (System no longer locked up) Console Regains Control (74 byte packet sent)
17:17:50.357555000 Contacts Crashlog Server/System Operation Resumes

Sandbox Exploitation

For some reason the system fails to perform any checks/verify certain sys library's before installing them. This allows you to replace those library files with your own binary. The system will install your packaged binary to the HDD as if it were a regular update. In order to run this binary, you need to meet all the requirements listed below.

Running your own code in sandbox requires 4 things:

1.Disabling SHA-1 Checksums ✔ useSha1Checksums = "false" OR -Change SHA-1 checksums to match modified pkg

2.Generate a valid signature/disable or bypass signature authentication ✖ Hash of container + Magic Number form signature -Hash can be computed from modified files -Magic Number = ???

3.Repacking Containers ✔ Lib pkg not signed or encrypted. You can modify everything as long as you don't change the structure.

4.Crafting proper binary ✔ Binary files in sandbox aren't signed or encrypted. If you use the proper version of the compiler (Get the ver info from the original binarys) you can craft a binary that's accepted as valid.

Assuming you can get code running disabling sandboxing is trivial.

Leap second 23:59:60 bug

http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Leap second 2015 June 30, 23h 59m 60s should theoretically not be a problem, since PS4 is based on BSD which can implement 23:59:60.

Patched

Decryption of any post-prototype and low FW PUP

• Discovered by flatz.

• A bug in the handlers of PUP decryption allows a PS4 on 1.62 or below to decrypt any PUP (retail, testkit, devkit, beta, prototype) with a version above 1.00 (post-prototype) or any PUP <= current PS4 FW.

• SM code doesn't reset state after SMI checks failure, so to decrypt arbitrary PUP, you need to ignore mailbox error after PupDecryptHeader cmd (1).

• Fixed around 1.70.

Decryption of any userland SELF from 1.00 to 3.70

• Sony reused keys from 1.00 to 3.70 on userland modules. as a result, any userland module from those versions can be decrypted on a PS4 between 1.00 and 3.70.

• Fixed in 4.00 with the introduction of new keyset.

Internal kernel table of symbols kept on very low versions

• Sony used to have two tables of symbols on very low versions: internal and external (internal had all symbols, external had 75% of them).

• Seen in 1.01 kernel. Patched somewhere around 1.05.

External kernel table of symbols kept on low versions

• After Sony removed internal table, they still kept the external one.

• Seen in 1.01-1.76 kernels. Patched somewhere around 2.50.

IDPS leak in sceSblAuthMgrDriveData on low retail versions

• Discovered by flatz

• Dumping IDPS from 2 EID blocks from kernel: sceSblAuthMgrDriveData(0, in_buf, 0x160, out_buf, 0xA4, 1). Pass 0x160 bytes at 0x90C00 from sflash0s1.crypt into `in buf` and dump buffers.

• It's possible because someone from sony forgot to encrypt output, that's how it was patched later.

• Patched between 1.76 retail and 4.05 retail. Works on any TestKit/DevKit FW.

Crashdumps encryption using symmetrical key and same key across fw

• see FoF article

• Patched on 4.50. Tested between 1.01 and 4.07.

Reference sites

• http://www.vulnerability-lab.com/
• http://seclists.org/
• http://cxsecurity.com/
• http://www.exploit-db.com/
• http://www.osvdb.org/
• http://www.cvedetails.com/vulnerability-list/vendor_id-6/Freebsd.html
• http://www.cvedetails.com/vulnerability-list/vendor_id-6/cvssscoremin-9/cvssscoremax-/Freebsd.html