Bugs: Difference between revisions

From PS4 Developer wiki
Jump to navigation Jump to search
 
(33 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== Theoretical Hardware Attacks ==
The PS4 has bugs. Some bugs can lead to [[Vulnerabilities]]. Others lead to nothing useful (yet) but can serve as examples of what not to do.  
We already know for certain someone out there has hacked the SAMU or stolen Sony's keys because of leaked decrypted kernels. PS4 has been out for 4 years or so and we are still running crappy browser based exploits. It is time to set up our console game people! These are some end all hardware solutions to hack the PS4 theorized by golden. I give a score out of 10 for each.


=== Power analysis against SAMU 4/10 ===
= Theoretical Hardware Attacks =
There are theories that this wont work because...
 
We already know for certain someone out there has hacked the SAMU or stolen Sony's keys because of leaked decrypted kernels. These are some end-all hardware solutions to hack the PS4, theorized by golden. I give a score out of 10 for each.
 
=== Power analysis against SAMU 9.9/10 ===
 
There are theories that this won't work because...
* SAMU silicon spoofs hamming weight (prevents differential power analysis and EM analysis)
* SAMU silicon spoofs hamming weight (prevents differential power analysis and EM analysis)
* It is running too fast and not feasible since cost is too high
* It is running too fast and not feasible since cost is too high
* You can't slow down the SAMU clock since it is internally checked
* You cannot slow down the SAMU clock since it is internally checked
* Some more issues?
* Some more issues?
If there is some sort of main CPU/SAMU PLL bypass we might be able to slow the clock down really easily, otherwise we must inject our own clock signal. I believe the SAMU clock is controlled by syscon? If the check is in syscon then we can just patch it out. Maybe write a custom Linux fork that never loads into userland but just sits and constantly decrypts different self/sprx files. We could communicate with this Linux fork over UART. This attack only needs to work once to recover some keys.
 
If there is some sort of main CPU/SAMU PLL bypass we might be able to slow the clock down really easily, otherwise we must inject our own clock signal. I believe the SAMU clock is controlled by syscon? If the check is in syscon then we can just patch it out. Maybe write a custom Linux fork that never loads into usermode but just sits and constantly decrypts different self/sprx files. We could communicate with this Linux fork over UART. This attack only needs to work once to recover some keys.


=== SAMU power/clock glitch fault injection 5/10 ===
=== SAMU power/clock glitch fault injection 5/10 ===
During an AES round we might be able to do some SCA by injecting faults. See the paper from umass.edu in the section below. We would write a minimal operating system to reboot into after exploiting an older firmware. This 'operating system' will simply shutdown most of the CPU cores and pin one core. This code would communicate with the SAMU and do everything the normal SCE SAMU driver does for decryption. We can then use UART output from CPU to time our glitch attacks. The faulty data retrieved by our custom SAMU driver might be able to reveal secret key data. This attack only needs to work once to recover some keys.
During an AES round we might be able to do some SCA by injecting faults. See the paper from umass.edu in the section below. We would write a minimal operating system to reboot into after exploiting an older firmware. This 'operating system' will simply shutdown most of the CPU cores and pin one core. This code would communicate with the SAMU and do everything the normal SCE SAMU driver does for decryption. We can then use UART output from CPU to time our glitch attacks. The faulty data retrieved by our custom SAMU driver might be able to reveal secret key data. This attack only needs to work once to recover some keys.


=== SAMU backside UV/IR fault injection 3/10 ===
=== SAMU backside UV/IR fault injection 3/10 ===
Just as the title states. Very expensive to setup and do properly. If we can flip an even number of bits it the encrypted SAMU SRAM region of the chip (even since ECC parity bit), then some sort of side channel analysis might be able to be done to recover key material. Some silicon reverse engineering would be involved to find the SRAM region on die.
Just as the title states. Very expensive to setup and do properly. If we can flip an even number of bits it the encrypted SAMU SRAM region of the chip (even since ECC parity bit), then some sort of side channel analysis might be able to be done to recover key material. Some silicon reverse engineering would be involved to find the SRAM region on die.


Line 21: Line 28:


=== SEM/FIB/microprobes 2/10 ===
=== SEM/FIB/microprobes 2/10 ===
We might be able to readout the bootrom with some microprobes? Sniff data lines somewhere? The SAMU SRAM memory is encrypted so we would have to probe the LM32 instruction bus or something... infeasible but possible.
We might be able to readout the bootrom with some microprobes? Sniff data lines somewhere? The SAMU SRAM memory is encrypted so we would have to probe the LM32 instruction bus or something... infeasible but possible.


=== Aeolia/Belize glitching 8/10 ===
=== USB ===
This is a theoretical hack to gain unsigned code execution on the southbridge for all motherboard/console revisions. You might be able to glitch the EMC bootrom in order to bypass further signature checks and break the chain of trust. You can attack the main FreeBSD kernel from here. This hack might involve slowing down the syscon clock. Timing the glitch based on SPI read accesses then either doing a power glitch or clock glitch to skip signature check. If the glitch fails, then we simply reset. This can be done with a very cheap CPLD/FPGA. Most Xbox 360 glitching modchips used a Xilinx Coolrunner because it is cheap and easy to use (board can cost as low as $5). This attack might not work due to unknown encryption keys.


=== USB pwnage ===
The FreeBSD USB stack has been theorized, by a well know security researcher, to contain some high profile bugs. A dongle might just be possible. For example, last year someone ran a fuzzer on the Linux USB stack and found some crazy bugs: https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md
The FreeBSD USB stack has been theorized, by a well know security researcher, to contain some high profile bugs. A dongle might just be possible. For example, last year someone ran a fuzzer on the Linux USB stack and found some crazy bugs: https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md


=== Bluetooth pwnage ===
=== Bluetooth ===
 
Look at Blueborne and CVE-2017-0781. There are probably some bugs in the Sony/FreeBSD Bluetooth stack. Sony has a habit of ruining their own copy and paste. One of the reasons fail0verflow decided to attack the DS4 controller firmware was because it had a nice interface to the kernel which could contain bugs.
Look at Blueborne and CVE-2017-0781. There are probably some bugs in the Sony/FreeBSD Bluetooth stack. Sony has a habit of ruining their own copy and paste. One of the reasons fail0verflow decided to attack the DS4 controller firmware was because it had a nice interface to the kernel which could contain bugs.


== Unknown / unpatched ==
= Software Bugs =


=== SnagFilms ===
=== SnagFilms ===
A possible exploit has been found in the SnagFilms app in the PSStore app.
 
A possible exploit has been found in the SnagFilms app in the PS Store 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.
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.
If you craft a small enough payload and/or a payload that loads without causing an exception in program memory, you can most likely get usermode code execution.
 
https://www.psdevwiki.com/ps4/File:5OrSFCa.jpg


http://i.imgur.com/5OrSFCa.jpg
=== BattleCars Exploit (Buffer Overflow in Rocket League) ===


=== (BattleCars Exploit-Rocket League) ===
Back in time, it affected the latest System Software version (2.57) and the most recent application version (1.03).
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/
First block all requests from:https://patch103-dot-psyonix-rl.appspot.com/


When you launch Rocket League it gets a stub file from:
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
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.
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 does not 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.
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.
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, etc.


Staying on the start screen for long enough can also trigger it.  
Staying on the start screen for long enough can also trigger it. If your payload is not created properly, it will take much longer to execute.
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.
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.
Line 64: Line 72:
http://sceecatalogs.vidzone.tv/469/vidzone_469_US.db.psarc
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
If your payload is crafted properly, you should be able to get it working within 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.
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.
It may also be possible to alter gameplay via similar methods.


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


=== VidNow (TCP Buffer Overflow) ===
=== VidNow (TCP Buffer Overflow) ===


A possible exploit has been found in VidNow app from the PSStore App.
A possible exploit has been found in VidNow app from the PS Store 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.


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 60 kB TCP buffer. No checks are done at all on the files sizes/hashes/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 bytes 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 usermode ROP code execution, among other things.


When you launch Vidnow for the first time it gets http://sceecatalogs.vidzone.tv/386/vidzone_386_US.db.psarc. This file is 5mb.
* Note: a related DRM file was available at: http://sceeassets.vidzone.tv/High/000/000/012/524/12524.drm.
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 ====
====  Crash Timeline ====
  17:17:39.899984000 Request
  17:17:39.899984000 Request
  17:17:40.000655000 Request
  17:17:40.000655000 Request
Line 88: Line 98:
  17:17:48.500567000 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.356427000 (System no longer locked up) Console Regains Control (74 byte packet sent)
  17:17:50.357555000 Contacts Crashlog Server/System Operation Resumes
  17:17:50.357555000 Contacts Crashlog Server / System Operation Resumes
 
=== Leap second 23:59:60 bug ===


=== Sandbox Exploitation ===
[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].
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:''
=== 6.20+ DevKit Specific Bug ===


1.''Disabling SHA-1 Checksums'' '''✔'''
<pre>
useSha1Checksums = "false"
The Development Kit comes with breakpoint feature that can pause the execution of an application program when the application program accesses a certain location in memory. This data breakpoint is only triggered when an application program accesses memory, but, because of a bug that occurred in version 6.00 of the system software, such breakpoints may be triggered when the kernel accesses the memory of an application program. When this happens, the PlayStation 4 system determines that a serious error has occurred and automatically shuts down the Development Kit.
OR
</pre>
-Change SHA-1 checksums to match modified pkg


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


3.''Repacking Containers'' '''✔'''
<pre>
Lib pkg not signed or encrypted. You can modify everything as long as you don't change the structure.
This bug occurs regardless of the method used to set the data breakpoint (occurring both when a breakpoint is set with the host tool and when it is set with the sceDbgSetHardwareBreakPoint() API). Version 6.50 of the system software will be fixed so that data breakpoints are not triggered when the kernel accesses an application program's memory (thus returning to the behavior of versions of the system software prior to version 6.00).
</pre>


4.''Crafting proper binary'' '''✔'''
= WebKit =
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.
== JIT disabled ==


=== Leap second 23:59:60 bug ===
<pre>
CVE-2023-41074
Affecting WebKitGTK.
CVE-2023-42917
Affecting WebKitGTK.
</pre>
 
=== FW ?10.00-11.52? - Immediate overflow/underflow in JSC SBFX (CVE-2024-27833) leading to arbitrary code execution ===
 
==== Credits ====
* Manfred Paul (@_manfp), working with Trend Micro Zero Day Initiative, for discovering the vulnerability on Apple Safari at pwn2own 2024 (2024-03-21) [https://twitter.com/thezdi/status/1770611705510293546 Zero Day Initiative's tweet]
* Justin Michaud for fix commit, Yusuke Suzuki for fix commit review (2024-05-15)
* Apple disclose that Safari update integrates the fix (2024-06-10)
* xvonfers and Bearseater (@JamesMa52390215) for discovering it affects PS4 and PS5 (2024-06-11) [https://twitter.com/xvonfers/status/1800426437486485635 xvonfer's tweet]
 
==== Analysis ====
* [https://github.com/WebKit/WebKit/commit/1ea4ef8127276fd00ca43ffcb22bed162072abde WebKit fix commit by Justin Michaud (2024-05-15)]
* [https://bugs.webkit.org/show_bug.cgi?id=271491 WebKit Bugzilla #271491 with restricted access]
 
==== Bug Description ====
There is an integer underflow in WebKit renderer. It was addressed with improved input validation.
 
The JavaScriptCore Isel SBFX patterns in JavaScriptCore/b3/B3LowerToAir.cpp allowed immediate overflow as 'lsb' and 'width' are not properly checked.
 
SBFX stands for Signed Bitfield Extract. See [https://www.scs.stanford.edu/~zyedidia/arm64/sbfx_sbfm.html] and [https://developer.arm.com/documentation/101273/0001/The-Cortex-M55-Instruction-Set--Reference-Material/Bit-field-instructions/SBFX-and-UBFX]. SBFX is an alias for SBFM (Signed Bitfield Move). See [https://www.scs.stanford.edu/~zyedidia/arm64/sbfm.html]. SBFM is a bitfield extraction opcode.
 
Isel is a short name for Instruction SELect. This pass transforms generic machine instructions into equivalent target-specific instructions. It traverses the MachineFunction bottom-up, selecting uses before definitions, enabling trivial dead code elimination.
 
==== Exploit Implementation ====
* [https://github.com/WebKit/WebKit/blob/main/JSTests/stress/sbfx-offset-overflow.js Vulnerability test by Justin Michaud]
 
==== Patched ====
'''Yes''' on PS4 FW 12.00 and PS5 FW ?10.00?.
 
==== Tested ====
Tested working on PS4 FWs 11.50 and PS5 FWs ?6.00-9.60?. Not working on PS4 <= 9.00 and PS5 >= 10.01.
----
 
=== FW ?10.00-11.02? - JSC::DFG::clobberize() needs to be more precise with the *ByOffset nodes (CVE-2023-41993) leading to arbitrary RW ===
 
==== Credits ====
* Bill Marczak of The Citizen Lab at The University of Toronto's Munk School and Maddie Stone of Google's Threat Analysis Group for discoverting the vulnerability and reporting it (2023-09-21)
* Keith Miller for the WebKit fix commit (2023-10-09)
* po6ix for his writeup (2023-10-15)
 
==== Analysis ====
* [https://github.com/WebKit/WebKit/commit/08d5d17c766ffc7ca6a7c833c5720eb71b427784 WebKit fix commit by Keith Miller (2023-10-09)]
* [https://github.com/po6ix/POC-for-CVE-2023-41993 Writeup by po6ix (2023-10-15)]
 
==== Bug Description ====
clobberize needs to be more precise with the *ByOffset nodes. CSE phase uses clobberize to figure out if it's safe to merge two operations that def the same HeapLocation. Since HeapLocation does not currently have a way to track the offset used by the various *ByOffset nodes it can get confused and think that two ByOffset instructions produce the same value even if they do not use the same offset. This patch solves this by adding a new field to HeapLocation, which takes the metadata associated with the corresponding *ByOffset node. If two *ByOffset operations don't share the same metadata then they cannot be CSEed.
 
This vulnerability is ranked 7.5 (HIGH) on CVSS:3.1.


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.
This vulnerability should provide r/w primitive to the webcontent process, but currently the PoC is written only up to addrof/fakeobj.


== Patched ==
==== Exploit Implementation ====
* [https://github.com/po6ix/POC-for-CVE-2023-41993 PoC written only up to addrof/fakeobj by po6ix (2023-10-15)]


=== Decryption of any post-prototype and low FW PUP ===
==== Patched ====
'''Maybe''' on PS4 FW 12.00 and PS5 ?10.00?


* Discovered by flatz.
==== Tested ====
Not tested yet. According to open source code, PS4 FW 11.00 should be vulnerable.
----


* 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.
=== FW 10.00-11.02 - JSC DFG Abstract Intepreter clobberWorld Type Confusion (no CVE) leading to crash ===


* 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).
==== Credits ====
* Alexey Shvayka for vulnerability discovery and fixes in WebKit (2023-05-01)
* ENKI for public disclose and writeup (2024-06-03)
* abc (anonymous) for tests and analysis (2024-10-01)


* Fixed around 1.70
==== Analysis ====
* [https://medium.com/@enki-techblog/ios-16-5-1-safari-rce-analysis-cve-2023-37450-89bb8583bebc Analysis by ENKI (2024-06-03)]
* [https://github.com/WebKit/WebKit/commit/1b0741f400ee2d31931ae30f2ddebe66e8fb0945 Patch commit #1 for vulnerability detection (2023-07-31)]
* [https://github.com/WebKit/WebKit/commit/39476b8c83f0ac6c9a06582e4d8e5aef0bb0a88f Patch commit #2 (2023-05-01)]
* [https://www.zerodayinitiative.com/blog/2018/4/12/inverting-your-assumptions-a-guide-to-jit-comparisons Inverting Your Assumptions: A Guide to JIT Comparisons by Jasiel Spelman (2018-04-12)]


=== Decryption of any userland SELF from 1.00 to 3.70 ===
==== Bug Description ====
Note that the PS4 web browser JIT support has been removed since around PS4 System Software version 5.00 or lower so using the article directly is not applicable.


* 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.
The clobber bug PoC turns out not to be a memory corruption. Just like the article said, you can access a `GetterSetter` directly. The crash came from triggering `GetterSetter`'s methods that will call `RELEASE_ASSERT()`.


* Fixed in 4.00 with the introduction of new keyset.
We actually have [[#FW_?6.00-11.52?_-_get_by_id_with_this_associated_with_ProxyObject_can_leak_JSScope_objects|a bug that can leak `GetterSetter`s]].


=== Internal kernel table of symbols kept on very low versions ===
In summary with tinkering with this bug, abc (anonymous) do not think that an attacker can do anything useful with accessing a `GetterSetter`. The clobberWorld bug however does allow setting properties in places where you usually cannot like `Function's prototype` as shown in the article. But without JIT, one probably cannot cause any memory corruption. The impact for both bugs (clobberWorld and ProxyObject) is probably just JavaScript execution, which we already have, which is a no go in some context (JS injection) but it does not help in gaining usermode ROP execution on PS4 or PS5.


* Sony used to have two tables of symbols on very low versions: internal and external (internal had all symbols, external had 75% of them).
==== Exploit Implementation ====
* [https://medium.com/@enki-techblog/ios-16-5-1-safari-rce-analysis-cve-2023-37450-89bb8583bebc PoC by ENKI (2024-06-03)]


* Seen in 1.01 kernel. Patched somewhere around 1.05.
==== Patched ====
'''Yes''' on PS4 FW 11.50 and PS5 FW 9.00.


=== External kernel table of symbols kept on low versions ===
==== Tested ====
Tested working on PS4 FWs 10.00-11.02 and PS5 FWs 6.00-8.60. PS4 FWs <= ?9.60? and PS5 FWs <= ?5.50? are invulnerable.
----


* After Sony removed internal table, they still kept the external one.
== Memory exhausted but not corrupted ==


* Seen in 1.01-1.76 kernels. Patched somewhere around 2.50.
=== FW ?10.00?-11.52 - Unknown heap and string overflow (no CVE) leading to crash ===


=== IDPS leak in sceSblAuthMgrDriveData on low retail versions ===
==== Credits ====
* Debty for PoC public disclose (2024-08-29)


* Discovered by flatz
==== Analysis ====
* [https://github.com/Debvt/Wm/tree/Root0 PoC and analysis by Debty (2024-08-29)]


* 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.
==== Bug Description ====
* TODO


* It's possible because someone from sony forgot to encrypt output, that's how it was patched later.
Implementation description by Debty:<br />
String exploit is not actually an exploit but just a memory exhauster. It is not actually viable so instead there is a feature called "latest iteration".


* Patched between 1.76 retail and 4.05 retail. Works on any TestKit/DevKit FW.
==== Exploit Implementation ====
* [https://github.com/Debvt/Wm/tree/Root0 PoC by Debty (2024-08-29)]


=== Crashdumps encryption using symmetrical key and same key across fw ===
==== Patched ====
'''Yes''' on PS4 FW 12.00 and PS5 FW 10.00.


* [https://fail0verflow.com/blog/2017/ps4-crashdump-dump/#crashdump-decryptor see FoF article]
==== Tested ====
Tested working on PS4 FWs 10.00-11.52 and PS5 FWs 6.00-9.60.
----


* Patched on 4.50. Tested between 1.01 and 4.07.
= Reference sites =


== Reference sites ==
* http://www.vulnerability-lab.com/
* http://www.vulnerability-lab.com/
* http://seclists.org/
* http://seclists.org/

Latest revision as of 21:31, 15 December 2024

The PS4 has bugs. Some bugs can lead to Vulnerabilities. Others lead to nothing useful (yet) but can serve as examples of what not to do.

Theoretical Hardware Attacks[edit | edit source]

We already know for certain someone out there has hacked the SAMU or stolen Sony's keys because of leaked decrypted kernels. These are some end-all hardware solutions to hack the PS4, theorized by golden. I give a score out of 10 for each.

Power analysis against SAMU 9.9/10[edit | edit source]

There are theories that this won't work because...

  • SAMU silicon spoofs hamming weight (prevents differential power analysis and EM analysis)
  • It is running too fast and not feasible since cost is too high
  • You cannot slow down the SAMU clock since it is internally checked
  • Some more issues?

If there is some sort of main CPU/SAMU PLL bypass we might be able to slow the clock down really easily, otherwise we must inject our own clock signal. I believe the SAMU clock is controlled by syscon? If the check is in syscon then we can just patch it out. Maybe write a custom Linux fork that never loads into usermode but just sits and constantly decrypts different self/sprx files. We could communicate with this Linux fork over UART. This attack only needs to work once to recover some keys.

SAMU power/clock glitch fault injection 5/10[edit | edit source]

During an AES round we might be able to do some SCA by injecting faults. See the paper from umass.edu in the section below. We would write a minimal operating system to reboot into after exploiting an older firmware. This 'operating system' will simply shutdown most of the CPU cores and pin one core. This code would communicate with the SAMU and do everything the normal SCE SAMU driver does for decryption. We can then use UART output from CPU to time our glitch attacks. The faulty data retrieved by our custom SAMU driver might be able to reveal secret key data. This attack only needs to work once to recover some keys.

SAMU backside UV/IR fault injection 3/10[edit | edit source]

Just as the title states. Very expensive to setup and do properly. If we can flip an even number of bits it the encrypted SAMU SRAM region of the chip (even since ECC parity bit), then some sort of side channel analysis might be able to be done to recover key material. Some silicon reverse engineering would be involved to find the SRAM region on die.

"Moreover, it is no longer possible to hit a single SRAM cell with the current etching technologies, since the width of the gate dielectric is now more than 10 times smaller than the shortest wavelength of visible light." To get an idea of the cost of this equipment... "A class of threats which cannot be ignored if the attackers have access to a larger budget (above the aforementioned $3000 and up to millions of dollars)" (http://euler.ecs.umass.edu/research/bbkn-IEEEP-2012.pdf)

The fault injection is all infeasible unless some elite hackzor came out of the woodwork. We only need to have this work once.

SEM/FIB/microprobes 2/10[edit | edit source]

We might be able to readout the bootrom with some microprobes? Sniff data lines somewhere? The SAMU SRAM memory is encrypted so we would have to probe the LM32 instruction bus or something... infeasible but possible.

USB[edit | edit source]

The FreeBSD USB stack has been theorized, by a well know security researcher, to contain some high profile bugs. A dongle might just be possible. For example, last year someone ran a fuzzer on the Linux USB stack and found some crazy bugs: https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md

Bluetooth[edit | edit source]

Look at Blueborne and CVE-2017-0781. There are probably some bugs in the Sony/FreeBSD Bluetooth stack. Sony has a habit of ruining their own copy and paste. One of the reasons fail0verflow decided to attack the DS4 controller firmware was because it had a nice interface to the kernel which could contain bugs.

Software Bugs[edit | edit source]

SnagFilms[edit | edit source]

A possible exploit has been found in the SnagFilms app in the PS Store 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 loads without causing an exception in program memory, you can most likely get usermode code execution.

https://www.psdevwiki.com/ps4/File:5OrSFCa.jpg

BattleCars Exploit (Buffer Overflow in Rocket League)[edit | edit source]

Back in time, it affected the latest System Software version (2.57) and the most recent application version (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 does not 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, etc.

Staying on the start screen for long enough can also trigger it. If your payload is not 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 within 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)[edit | edit source]

A possible exploit has been found in VidNow app from the PS Store 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 60 kB TCP buffer. No checks are done at all on the files sizes/hashes/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 bytes 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 usermode ROP code execution, among other things.

Crash Timeline[edit | edit source]

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

Leap second 23:59:60 bug[edit | edit source]

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.

6.20+ DevKit Specific Bug[edit | edit source]

The Development Kit comes with breakpoint feature that can pause the execution of an application program when the application program accesses a certain location in memory. This data breakpoint is only triggered when an application program accesses memory, but, because of a bug that occurred in version 6.00 of the system software, such breakpoints may be triggered when the kernel accesses the memory of an application program. When this happens, the PlayStation 4 system determines that a serious error has occurred and automatically shuts down the Development Kit.

6.50 DevKit Specific Bug[edit | edit source]

This bug occurs regardless of the method used to set the data breakpoint (occurring both when a breakpoint is set with the host tool and when it is set with the sceDbgSetHardwareBreakPoint() API). Version 6.50 of the system software will be fixed so that data breakpoints are not triggered when the kernel accesses an application program's memory (thus returning to the behavior of versions of the system software prior to version 6.00).

WebKit[edit | edit source]

JIT disabled[edit | edit source]

CVE-2023-41074
Affecting WebKitGTK.
	
CVE-2023-42917
Affecting WebKitGTK.

FW ?10.00-11.52? - Immediate overflow/underflow in JSC SBFX (CVE-2024-27833) leading to arbitrary code execution[edit | edit source]

Credits[edit | edit source]

  • Manfred Paul (@_manfp), working with Trend Micro Zero Day Initiative, for discovering the vulnerability on Apple Safari at pwn2own 2024 (2024-03-21) Zero Day Initiative's tweet
  • Justin Michaud for fix commit, Yusuke Suzuki for fix commit review (2024-05-15)
  • Apple disclose that Safari update integrates the fix (2024-06-10)
  • xvonfers and Bearseater (@JamesMa52390215) for discovering it affects PS4 and PS5 (2024-06-11) xvonfer's tweet

Analysis[edit | edit source]

Bug Description[edit | edit source]

There is an integer underflow in WebKit renderer. It was addressed with improved input validation.

The JavaScriptCore Isel SBFX patterns in JavaScriptCore/b3/B3LowerToAir.cpp allowed immediate overflow as 'lsb' and 'width' are not properly checked.

SBFX stands for Signed Bitfield Extract. See [1] and [2]. SBFX is an alias for SBFM (Signed Bitfield Move). See [3]. SBFM is a bitfield extraction opcode.

Isel is a short name for Instruction SELect. This pass transforms generic machine instructions into equivalent target-specific instructions. It traverses the MachineFunction bottom-up, selecting uses before definitions, enabling trivial dead code elimination.

Exploit Implementation[edit | edit source]

Patched[edit | edit source]

Yes on PS4 FW 12.00 and PS5 FW ?10.00?.

Tested[edit | edit source]

Tested working on PS4 FWs 11.50 and PS5 FWs ?6.00-9.60?. Not working on PS4 <= 9.00 and PS5 >= 10.01.

FW ?10.00-11.02? - JSC::DFG::clobberize() needs to be more precise with the *ByOffset nodes (CVE-2023-41993) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Bill Marczak of The Citizen Lab at The University of Toronto's Munk School and Maddie Stone of Google's Threat Analysis Group for discoverting the vulnerability and reporting it (2023-09-21)
  • Keith Miller for the WebKit fix commit (2023-10-09)
  • po6ix for his writeup (2023-10-15)

Analysis[edit | edit source]

Bug Description[edit | edit source]

clobberize needs to be more precise with the *ByOffset nodes. CSE phase uses clobberize to figure out if it's safe to merge two operations that def the same HeapLocation. Since HeapLocation does not currently have a way to track the offset used by the various *ByOffset nodes it can get confused and think that two ByOffset instructions produce the same value even if they do not use the same offset. This patch solves this by adding a new field to HeapLocation, which takes the metadata associated with the corresponding *ByOffset node. If two *ByOffset operations don't share the same metadata then they cannot be CSEed.

This vulnerability is ranked 7.5 (HIGH) on CVSS:3.1.

This vulnerability should provide r/w primitive to the webcontent process, but currently the PoC is written only up to addrof/fakeobj.

Exploit Implementation[edit | edit source]

Patched[edit | edit source]

Maybe on PS4 FW 12.00 and PS5 ?10.00?

Tested[edit | edit source]

Not tested yet. According to open source code, PS4 FW 11.00 should be vulnerable.

FW 10.00-11.02 - JSC DFG Abstract Intepreter clobberWorld Type Confusion (no CVE) leading to crash[edit | edit source]

Credits[edit | edit source]

  • Alexey Shvayka for vulnerability discovery and fixes in WebKit (2023-05-01)
  • ENKI for public disclose and writeup (2024-06-03)
  • abc (anonymous) for tests and analysis (2024-10-01)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Note that the PS4 web browser JIT support has been removed since around PS4 System Software version 5.00 or lower so using the article directly is not applicable.

The clobber bug PoC turns out not to be a memory corruption. Just like the article said, you can access a `GetterSetter` directly. The crash came from triggering `GetterSetter`'s methods that will call `RELEASE_ASSERT()`.

We actually have a bug that can leak `GetterSetter`s.

In summary with tinkering with this bug, abc (anonymous) do not think that an attacker can do anything useful with accessing a `GetterSetter`. The clobberWorld bug however does allow setting properties in places where you usually cannot like `Function's prototype` as shown in the article. But without JIT, one probably cannot cause any memory corruption. The impact for both bugs (clobberWorld and ProxyObject) is probably just JavaScript execution, which we already have, which is a no go in some context (JS injection) but it does not help in gaining usermode ROP execution on PS4 or PS5.

Exploit Implementation[edit | edit source]

Patched[edit | edit source]

Yes on PS4 FW 11.50 and PS5 FW 9.00.

Tested[edit | edit source]

Tested working on PS4 FWs 10.00-11.02 and PS5 FWs 6.00-8.60. PS4 FWs <= ?9.60? and PS5 FWs <= ?5.50? are invulnerable.

Memory exhausted but not corrupted[edit | edit source]

FW ?10.00?-11.52 - Unknown heap and string overflow (no CVE) leading to crash[edit | edit source]

Credits[edit | edit source]

  • Debty for PoC public disclose (2024-08-29)

Analysis[edit | edit source]

Bug Description[edit | edit source]

  • TODO

Implementation description by Debty:
String exploit is not actually an exploit but just a memory exhauster. It is not actually viable so instead there is a feature called "latest iteration".

Exploit Implementation[edit | edit source]

Patched[edit | edit source]

Yes on PS4 FW 12.00 and PS5 FW 10.00.

Tested[edit | edit source]

Tested working on PS4 FWs 10.00-11.52 and PS5 FWs 6.00-9.60.

Reference sites[edit | edit source]

Reverse Engineering
Bootprocess  ·  BootLogo  ·  DataBases  ·  Disc Identification/Serialization Data  ·  Files on the PS4  ·  IOCTL  ·  Libraries  ·  Partitions  ·  Syscalls  ·  Kernel Patches  ·  sealedkey / pfsSKKey  ·  VTRM  ·  Bugs  ·  Vulnerabilities  ·  SBL  ·  Devices  ·  Registry  ·  Build Strings  ·  QA Flagging  ·  Strings  ·  Hardware Info
Dumps & Strings
Dumps
Strings
Communication
USB
Wifi/LAN
Keys, Commands & Digests
Emulation
General
Compatibility Lists
System Modules
Retrieved from "http://www.psdevwiki.com/ps4/index.php?title=Bugs&oldid=294424"