Editing Vulnerabilities

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 125: Line 125:


==== Analysis ====
==== Analysis ====
* [https://github.com/TheOfficialFloW/Presentations/blob/master/2022-hardwear-io-bd-jb.pdf Pages 27 and 28 of slides presented at hardwear.io by TheFloW (2022-06-10)]
* [https://twitter.com/theflow0/status/1701154155744645349 Removed tweet of BD-JB2 logs on a 7.61 PS5 by TheFloW (2023-09-11)]
* [https://twitter.com/theflow0/status/1701154155744645349 Removed tweet of BD-JB2 logs on a 7.61 PS5 by TheFloW (2023-09-11)]
* [https://github.com/TheOfficialFloW/bd-jb/commit/44713ef59f897ff2125efccbdcb5d07dbe1ffdb5 Diff between UserPreferenceManagerImpl hijack and Path traversal sandbox escape implementations by TheFloW (2024-11-28)]


==== Bug Description ====
==== Bug Description ====
Basing on the BD-JB1 exploit files, in /bdmv/bdjo.xml changing bdjo/applicationManagementTable/baseDirectory to a path of the form `file:///app0/cdc/lib/../../../disc/BDMV/JAR/00000.jar` allows loading a JAR Java executable file. This vulnerability can efficiently replace the UserPreferenceManagerImpl to extend the supported System Software versions range compared to BD-JB1.
Basing on BD-JB1 exploit files, in /bdmv/bdjo.xml changing bdjo/applicationManagementTable/baseDirectory to a path of the form `file:///app0/cdc/lib/../../../disc/BDMV/JAR/00000.jar` allows loading a JAR Java executable file.


==== Exploit Implementation ====
==== Exploit Implementation ====
* [https://twitter.com/theflow0/status/1717088032031982066 Removed PoC by TheFloW (2023-10-25)]
* [https://twitter.com/theflow0/status/1717088032031982066 PoC by TheFloW (2023-10-25)]
* [https://github.com/TheOfficialFloW/bd-jb/blob/d21fd76c0768d05ad01c4722eb21480fa8a8b619/src/com/bdjb/Loader.java#L62 Implementation by TheFloW (2024-11-28)]


==== Patched ====
==== Patched ====
'''No''' as of PS4 FW 10.71 (maybe patched on PS4 FW 11.00). '''Yes''' on PS5 FW 8.00. Probably not patched on PS3.
'''No''' as of PS4 FW 10.71 (maybe patched on PS4 FW 11.00). '''Yes''' on PS5 FW 8.00.


=== FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW ===
=== FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW ===
Line 153: Line 150:


==== Bug Description ====
==== Bug Description ====
This exploit chain alone does not allow one to run pirated games on PS4 or PS5 as there is not enough RAM allowed in the BD-J process and there are other constraints.
TO ADD DESCRIPTION OF EACH ONE OF THE 5 BUGS:


TODO!: ADD DESCRIPTION OF EACH ONE OF THE 5 BUGS:
* #1 com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl userprefs hijack leading to classes instantiation under privileged context (affecting ?PS3?, PS4, PS5)
* #2 com.oracle.security.Service leading to privileged constructor call (affecting ?PS3?, PS4, not PS5)
* #3 com.sony.gemstack.org.dvb.io.ixc.IxcProxy leading to privileged method call (affecting ?PS3?, PS4, PS5)
* #4 JIT compiler hack leading to usermode arbitrary RW and arbitrary usermode code execution (affecting ?PS3?, PS4, not PS5)
* #5 UDF buffer overflow kernel exploit (affecting ?PS3?, PS4, PS5)


===== #1 - userprefs hijack (?PS3?, PS4, PS5) =====
This exploit chain alone does not allow one to run pirated games on PS4 or PS5 as there is not enough RAM allowed in the BD-J process and there are other constraints.
 
com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl userprefs hijack leads to classes instantiation under privileged context.
 
===== #2 - com.oracle.security.Service (?PS3?, PS4, not PS5) =====
 
com.oracle.security.Service leads to privileged constructor call.
 
===== #3 - com.sony.gemstack.org.dvb.io.ixc.IxcProxy leading to privileged method call (?PS3?, PS4, PS5) =====
 
com.sony.gemstack.org.dvb.io.ixc.IxcProxy leads to privileged method call.
 
===== #4 - JIT compiler hack (?PS3?, PS4, not PS5) =====
 
JIT compiler hack leads to usermode arbitrary RW and usermode arbitrary code execution.
 
===== #5 - UDF buffer overflow (?PS3?, PS4, PS5) =====
 
The UDF driver in kernel contains a buffer overflow. Note that no implementation of the UDF kernel exploit has ever been done even by TheFloW, only a kernel panic PoC.


==== Exploit Implementation ====
==== Exploit Implementation ====
Line 957: Line 940:
* See the PS4 [[Syscalls]] list.
* See the PS4 [[Syscalls]] list.


=== Direct Syscall invocation disabled in PS4 Kernel ===
=== Direct Syscalls disabled (PS4 only) i.e Error Kernel: The application directly issues a syscall instruction (24) ===
Between 2.00 and 2.57, SCE has removed direct system calls, we can no longer call any syscall we want by specifying the call number in the rax register and jump directly to the call part of a syscall stub. <code>amd64_syscall</code> checks the following:


Between 2.00 and 2.57, SCE has disabled direct system calls by usermode, by adding some checks in the PS4 kernel. An attacker can no longer call any syscall he wants by specifying the call number in the rax register and jump directly to the call instructions part of a syscall stub. Indeed, now the PS4 (but not PS5) implementation of <code>amd64_syscall</code> checks the following:
* The address (instruction pointer / IP) of the call is within the memory range of the associated libkernel of the process.
* The address in the Instruction Pointer (IP) of the call must be within the memory range of the associated libkernel module of the process,
* The code pointed by the IP follows the syscall stub format.
* The code pointed by the Instruction Pointer (IP) must follow the syscall stub format,
* The syscall number passed actually corresponds to the stub's syscall number. <code>amd64_syscall</code> checks the stub's <code>mov rax, syscall_number</code> instruction.
* The syscall number passed in argument to <code>amd64_syscall</code> must corresponds to the stub's syscall number. <code>amd64_syscall</code> checks the stub's <code>mov rax, syscall_number</code> instruction.


Since PS4 version 3.00, issuing directly a syscall instruction crashes the application and gives error CE-34878-0, (<code>SCE_KERNEL_ABORT_REASON_SYSTEM_ILLEGAL_FUNCTION_CALL</code>), displaying the message "Kernel: The application directly issues a syscall instruction (24)".
Doing so now crashes the app and gives error CE-34878-0, SCE_KERNEL_ABORT_REASON_SYSTEM_ILLEGAL_FUNCTION_CALL, with the message "Kernel: The application directly issues a syscall instruction (24)".


An attacker is now forced to use wrappers provided from the libkernel / libkernel_web / libkernel_sys modules to trigger system calls.
We now have to use wrappers provided to us from the libkernel / libkernel_web / libkernel_sys modules to access system calls.


The PS5 does not enforce the passed syscall number and thus any code can directly issue an arbitrary syscall even if the associated libkernel does not provide it.
PS5 doesn't enforce the passed syscall number and thus any code can directly issue an abitrary syscall even if the associated libkernel doesn't provide it.


=== bpf_write function stripped out of the kernel ===
=== bpf_write function stripped out of the kernel ===
Line 1,537: Line 1,520:
* Discovered by yifan lu (2017-02-19), plutoo and Proxima (2018-08-09), Davee (2018-12-29) for PS Vita, by flatz (2021-12-18) for PlayStation 4.
* Discovered by yifan lu (2017-02-19), plutoo and Proxima (2018-08-09), Davee (2018-12-29) for PS Vita, by flatz (2021-12-18) for PlayStation 4.


==== Bug description ====
=== Bug description ===
 
The PS4 Crypto Coprocessor (CCP) interface in Secure Kernel has a bug that allows to dump (or better saying, bruteforce) key rings from SAMU. A crypto flaw was in the ability to issue HMAC operation with key length stricly lower than 16. For example, by setting it to 1 you can bruteforce key bytes one by one by comparing HMAC result with HMAC result with known partial key.
 
This trick may work on other crypto hardware as well if it does not restrict key lengths. Amazingly, Intel Secure Key Storage (SKS) of CSME subsystem also has a bug allowing to brute-force any key slot, but the issue exists at hardware level - insecure design of the keys distribution to crypto engines (AES, SHA, RC4). Intel did not recognize the bug arguing that to access SKS the CSME privileged arbitrary code execution is required, but SKS is exactly designed to protect the ROM generated keys from CSME firmware...
 
This exploit can be used to dump the PFS AES XTS and HMAC keys of a specific PS4 game PKG. Then one can use maxton's LibOrbisPkg or flatz's pkg_pfs_tool to unpack this PKG file.
 
It also lets one retrieve portability master keys. They decrypt blobs (stored in non-secure world, like in [[SceShellcore]]) that contain the portability keys.
 
Below is a sample code to dump some "raw" keys (as named by flatz).
<source lang="C">
unsigned int key_count = 0x160;
unsigned int max_key_size = 0x40;
unsigned int *key_ids = (unsigned int *) malloc (key_count * 4);
unsigned int key_id = 0;
while (key_id < 0x160) {
    key_ids[key_id] = key_id;
    key_id++;
}
uint8_t* key_data = NULL;
size_t key_data_size = 0;
dump_raw_keys(key_ids, key_count, max_key_size, &key_data, &key_data_size);
hexdump(&key_data, &key_data_size);
</source>
 
A sample code to dump portability keys is available on [https://github.com/SiSTR0/ps4-hen-vtx/compare/master...jocover:ps4-hen-vtx:samu_key_dump#diff-e44475b3203baef04439ee15f01629a5752685028fc9118e3d2087dab7379698R908 line 908 of kpayload/source/samu_dump.c]. Note that not all keys are used as some may be deprecated or added with System Software revisions.


Dumped savedata keys would be per-save, as the dumped key ring should only contain the derivated key (XTS) but not the one used to generate it.
The PS4 Crypto Coprocessor (CCP) interface in Secure Kernel has a bug that allows to dump (or better saying, bruteforce) key rings from SAMU.
That is how AES/HMAC keys from PFS, portability keys, VTRM keys, etc can be retrieved. A crypto flaw was in the ability to issue HMAC operation with key length stricly lower than 16. For example, by setting it to 1 you can bruteforce key bytes one by one by comparing HMAC result with HMAC result with known partial key.


Finally, one can retrieve its per-console VTRM keys (which are notably used for per-account securities like for act.dat and [[RIF]]).
This trick may work on other crypto hardware as well if it does not restrict key lengths. Amazingly, Intel Secure Key Storage (SKS) of CSME subsystem also has a bug allowing to brute-force any key slot, but the issue exists at hardware level - insecure design of  the keys distribution to crypto engines (AES, SHA, RC4). Intel did not recognize the bug arguing that to access SKS the CSME privileged arbitrary code execution is required, but SKS is exactly designed to protect the ROM generated keys from CSME firmware...


However, master keyrings are the 0, 1, and 2 ones and cannot be dump them with this trick because they get locked during the [[bootprocess]] and cannot be read nor written nor copied to other keyrings. See also [https://wiki.henkaku.xyz/vita/Cmep_Key_Ring_Base PS Vita keyrings].
This can be used to dump the AES XTS key and HMAC key of a specific PS4 game PKG. Then one can use maxton's LibOrbisPkg or flatz's pkg_pfs_tool to unpack this PKG file.


==== Analysis ====
==== Analysis ====
Line 1,576: Line 1,534:
* https://twitter.com/qlutoo/status/1027691272369262594
* https://twitter.com/qlutoo/status/1027691272369262594
* https://www.lolhax.org/2019/01/02/extracting-keys-f00d-crumbs-raccoon-exploit/
* https://www.lolhax.org/2019/01/02/extracting-keys-f00d-crumbs-raccoon-exploit/
* [https://twitter.com/flat_z/status/1472243592815169546 Short explanation by flatz (2021-12-18)]
* https://twitter.com/flat_z/status/1472243592815169546


==== Implementation ====
==== Implementation ====


* [https://github.com/jocover/ps4-hen-vtx/releases/tag/pfs_dump Compiled payload for PS4 5.05 by jogolden (2023-03-18)]
* [https://github.com/jocover/ps4-hen-vtx/releases/tag/pfs_dump Compiled payload for PS4 5.05 by jogolden]
* [https://github.com/jocover/ps4-hen-vtx/tree/samu_key_dump Implementation for PS4 5.05 by jogolden (2023-03-18)]
* [https://github.com/jocover/ps4-hen-vtx/tree/samu_key_dump Implementation for PS4 5.05 by jogolden]
* [https://github.com/SiSTR0/ps4-hen-vtx/compare/master...jocover:ps4-hen-vtx:samu_key_dump Minimal implementation for PS4 5.05 by jogolden (2023-03-18)]
* [https://gist.github.com/flatz/22215327864d7512e52268f9c9c51cd8 Exploit PoC for PS4 7.55 by flatz]
* [https://gist.github.com/flatz/22215327864d7512e52268f9c9c51cd8 Exploit PoC for PS4 7.55 by flatz (2021-12-18)]


==== Patched ====
==== Patched ====
Please note that all contributions to PS4 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS4 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)