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 1: Line 1:
== Usermode Exploits (Game Savedata) ==
== To sort exploits ==


=== PS1 games savedata exploits ===
=== Decryption of any GEN3 PUP ===


See [[PS1 Emulation]] for a list of candidate games.
* Discovered by flatz.


See [https://www.psdevwiki.com/ps1/Vulnerabilities PS1 Dev Wiki] for a list of PS1 savedata exploits.
* A bug in the handlers of PUP decryption allows any PS4 on FW 1.62 GEN3 or below to decrypt any GEN3 PUP (retail, testkit, devkit, beta) with a version above 1.00 (post-prototype).


=== PS2 games savedata exploits ===
* 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).


See [[PS2 Emulation]] for a list of candidate games.
* Fixed around 1.70


See [https://www.psdevwiki.com/ps2/Vulnerabilities#PS2_Savedata_exploits PS2 Dev Wiki] for a list of PS2 savedata exploits.
=== Decryption of any usermode SELF from FW 1.00 to 3.70 ===


=== PSP games savedata exploits ===
* Sony reused keys from FW 1.00 to 3.70 on usermode modules. As a result, any usermode module from those FWs can be decrypted on a PS4 running FW between 1.00 and 3.70.


See [[PSP Emulation]] for a list of candidate games.
* Fixed in 4.00 with the introduction of new keyset.


See [https://www.psdevwiki.com/psp/Vulnerabilities PSP Dev Wiki] for a list of PSP savedata exploits.
=== .strtab/.symtab kernel table of symbols kept on very low FWs ===


=== PS4/PS5 PS2emu sandbox escape (mast1c0re) ===
* Sony used to have two tables of symbols on very low versions: .strtab/.symtab and .dynstr/.dynsym (.strtab/.symtab had all symbols, .dynstr/.dynsym had ~75% of them).


Advantages of the PS4/PS5 PS2emu sandbox escape exploit over most WebKit exploits:
* Seen in 1.01 kernel. Patched in 1.03.
* Bigger kernel attack surface (more usermode privileges) versus WebKit very restricted and becoming more and more with firmware revisions. For example, the PS2emu process uses libkernel_sys, which supports nmount and so mounting of system partitions, whilst neither libkernel_web nor regular libkernel do.
* 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions
* Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update


==== Credits ====
=== .dynstr/.dynsym kernel table of symbols kept on low FWs ===
* CTurt for discovering these vulnerabilities in September 2021.
* CTurt for public disclosure [https://twitter.com/CTurtE/status/1570189920844804097 on twitter] (2022-09-14).
* flatz, balika011, theflow0, chicken(s), PlayStation for helping CTurt.
* McCaulay for sharing publicly his implementation in February 2023.


==== Analysis ====
* After Sony removed  .strtab/.symtab, they still kept the .dynstr/.dynsym one.
* [https://cturt.github.io/mast1c0re.html Writeup part 1 by CTurt (2022-09-14)]
* [https://mccaulay.co.uk/mast1c0re-part-3-escaping-the-emulator Writeup part 3 by McCaulay (2023-02-17)]
* [https://cturt.github.io/mast1c0re-2.html Writeup part 2 by CTurt (2023-04-02)]


==== Bug Description ====
* Patched in 2.50
After getting code execution in a PS2onPS4 game using a savedata exploit, it is possible to exploit the PS2 emulator to get x86-64 usermode ROP execution. It is then possible, without a kernel exploit, to load another PS2 game in the emulator with a compatibility rate based on the PS2 emulator configuration.


==== Exploit Implementation ====
=== IDPS leak in sceSblAuthMgrDriveData on low retail FWs ===
* [https://github.com/McCaulay/mast1c0re mast1c0re implementation by McCaulay (2023-02-18)]


==== Patched ====
* Discovered by flatz.
'''No''' as of PS4 FW 11.50 and PS5 FW 8.00. Using the PS2onPS4 game Okage Shadow King, the exploit should work starting from PS4 FW 3.15 and PS5 FW 1.00.


=== PS4/PS5 game savedata Lua exploit ===
* Dump 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 `out_buf`.


==== Credits ====
* It is possible because someone from sony forgot to encrypt output and that is how it was patched later.
* Used by Flatz on 2023-07-27 in [https://wololo.net/2023/07/28/ps5-flat_z-dumps-ps5-secure-processor-confirms-he-has-a-ps5-hypervisor-exploit-via-a-ps4-game-save-exploit/ his Hypervisor exploit].
* Used by Flatz on 2024-09-14 in [https://gist.github.com/flatz/5e12f75cdb210516d31df03069f7ed0a his implementation of the umtx UaF kernel exploit].
* Lua sandbox escape makers (to document): Peter Cawley (corsix), erezto, Morgan Jones (numinit), Maxim Ivanov (ulidtko)


==== Bug description ====
* Patched in 3.00 retail. Works on any TestKit/DevKit FW.
Some PS4 (and maybe PS5) games, in disc version (usually also available in PS Store version, some even in free demo version, but potentially patched), can be exploited as they allow the user to execute Lua code by crafting an evil save data. By running malicious Lua code, the attacker can escape the Lua sandbox and obtain usermode arbitrary read-write then ROP chain execution in usermode.


On PS Vita, you can simply install the DRM demos, the same way as you would for Bitter Smile Demo (see h-encore by TheFloW).
=== Partial SAMU KeyRings bruteforce by missing HMAC length check in secure kernel ===


If you have access to the PS4/PS5 PS Store, you can simply buy the trial version to test it.
* Discovered by flatz.


Artemis and MUGEN engines are known to use Lua and so are vulnerable to various sandbox escape exploits.
* 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 ability to issue HMAC operation with key length < 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.  


Most of Artemis games automatically load save9999.dat file from save data folder when the game boots. By editing this file, one can load custom LUA scripts.
* 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 didn't 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...


Game boots -> "save9999.dat" is loaded -> "inject.iet" is loaded -> "inject.lua" is loaded.
Related:


You might have to create a different save9999.dat file for each game as the Lua interpreter version might differ.
* https://twitter.com/qlutoo/status/1027691272369262594


On Windows, you have access to luasocket and os.execute. However, on PS Vita/PS4/PS5, you have limited access.
* https://yifan.lu/2017/02/19/psvimgtools-decrypt-vita-backups/


You have to copy PS Vita/PS4/PS5 savedata files to the console.
* https://www.lolhax.org/2019/01/02/extracting-keys-f00d-crumbs-raccoon-exploit/


==== Vulnerable games ====
* [https://gist.github.com/flatz/22215327864d7512e52268f9c9c51cd8 Exploit PoC for PS4 FW 7.55]
See [[Artemis Engine]] for a list of candidate games.


Confirmed exploitable games:
* Patched since a FW between 7.55 (unpatched) and 9.00 (patched).
* Raspberry Cube (CUSA16074)
* Aibeya (CUSA17068)
* Hamidashi Creative (CUSA27389)
* Hamidashi Creative Demo (CUSA27390)


Other games that may use Lua scripts:
=== Crashdumps encryption using symmetrical key and same key across FW ===
* Pay Day 2, Mafia III, God of War (which one?).
* Games using the MUGEN engine are vulnerable to many exploits, but it is unknown if some PS4 games use this engine. https://mugen-cheap.fandom.com/wiki/SuperNull


==== Analysis ====
* [https://fail0verflow.com/blog/2017/ps4-crashdump-dump/#crashdump-decryptor see FoF article]


==== Exploit Implementation ====
* The keys never changed between 1.01 and 3.15 FWs. Then between 3.50 and 4.07 FWs they changed the keys many times but still used symmetrical key.
* [https://github.com/shahrilnet/remote_lua_loader/blob/b5f2420495e66308de06934530b3c449ab4bcf9b/savedata/inject.lua#L793 Lua ?5.1? sandbox escape in PS4 games running Artemis engine by shahrilnet (2024-11-25)]
* [https://gist.github.com/flatz/cbb84539aeee1ade1983ee2eea499dbc ROP chain manager in Lua by flatz (2024-11-02)]
* [https://github.com/Gezine/ArtemisLuaLoader Lua script execution PoC for Raspberry Cube (PS4 CUSA16074 and Windows) by Gezine (2024-10-06)]
* [https://github.com/erezto/lua-patcher LUA 5.1-5.3 bytecode patching tool by erezto (2015-10-19)]
* [https://github.com/erezto/lua-sandbox-escape/blob/master/x86_64/exploit.lua Lua 5.2 sandbox escape for x86 and x86-64 by erezto (2016-04-27)]
* [https://github.com/adamivora/lua-hardening-suite/tree/main/exploits Various Lua exploits by Adam Ivora (adamivora) (2023-12-14)]
* [https://web.archive.org/web/20201029040829/https://apocrypha.numin.it/talks/lua_bytecode_exploitation.pdf Escaping the Lua 5.2 sandbox with untrusted bytecode by Morgan Jones (numinit) (2016-09-12)]
* [https://www.corsix.org/content/malicious-luajit-bytecode Malicious LuaJIT bytecode by Peter Cawley (corsix) (2015-11-11)]
* [https://gist.github.com/corsix/49d770c7085e4b75f32939c6c076aad6 Exploiting Lua 5.2 on x64 by Peter Cawley (corsix) (2016-08-21)]
* [https://gist.github.com/ulidtko/51b8671260db79da64d193e41d7e7d16 Exploiting Lua 5.1 with bytecode type confusion on 32-bit Windows by Maxim Ivanov (ulidtko) (2018-03-21)]
* [https://gist.github.com/corsix/6575486 Exploiting Lua 5.1 on 32-bit Windows by Peter Cawley (corsix) (2013-09-16)]
* [https://gist.github.com/corsix/1fc9b13a2dd5f3659417b62dd54d4500 LuaJIT 2.1.0beta1 string hash table collision by Peter Cawley (corsix) (2019-04-27)]
* [https://github.com/gonzalezjo/ljhashdos LuaJIT 2.1.0beta1 string hash table collision by gonzalezjo (2018-07-09)]
* [https://benmmurphy.github.io/blog/2015/06/04/redis-eval-lua-sandbox-escape/ Redis EVAL Lua Sandbox Escape by Ben Murphy (2015-06-04)]
* [https://www.youtube.com/watch?v=8Q0KLTma_FA LuaJIT, something interesting inside at Lua Workshop 2016 by Peter Cawley (corsix) (2016-12-04)]
* [https://www.youtube.com/watch?v=OSMOTDLrBCQ Lua: Mitigating the Danger of Malicious Bytecode at Lua Workshop 2011 by Peter Cawley (corsix) (2011-09-08)]
* [https://github.com/ZiddiaMUGEN/LuaSupernull Lua exploits for the MUGEN 1.1 engine]
* [https://www.lua.org/bugs.html Lua bugs for any version disclosed by lua.org]


==== Patched ====
* Patched on FW 4.50 by using asymmetrical key. Tested between 1.01 and 4.07 FWs.
'''No''' as of PS4 FW ?12.00? and PS5 FW 7.61.


== Usermode Exploits (BD-J) ==
== Hardware Exploits ==


Advantages of most BD-J exploits over most WebKit exploits:
=== PCIe man-in-the-middle attack ===
* Bigger kernel attack surface (more usermode privileges) versus WebKit very restricted and becoming more and more with firmware revisions. For example, the BD-J process uses libkernel_sys, which supports nmount and so mount of system partitions, whilst neither libkernel_web nor regular libkernel do.
* 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions
* Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update
* JIT enabled allowing to write a kernel exploit in C versus writing in assembly and JavaScript since around FW 2.00


=== FW <= 10.71 - BD-JB2 - Path traversal sandbox escape by TheFloW ===
* First done on 1.01 by failoverflow on PS4 launch !
* Detailed at 33c3: [https://fail0verflow.com/media/33c3-slides/#/5 33c3 slides by Marcan]
* Permits kernel and usermode dumping


==== Credits ====
=== Syscon glitching ===
* TheFloW for the exploits finding (before 2023-09-11), ethical disclose to SCE (2023-09-22) and public disclosure (2023-10-25)
* Previous BD-JB contributors


==== Analysis ====
It is possible to glitch the [[Syscon]] debug interface to allow access and dump keys. It was originally done by an anonymous member of fail0verflow.
* [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://github.com/TheOfficialFloW/bd-jb/commit/44713ef59f897ff2125efccbdcb5d07dbe1ffdb5 Diff between UserPreferenceManagerImpl hijack and Path traversal sandbox escape implementations by TheFloW (2024-11-28)]


==== Bug Description ====
=== Aeolia and Belize (Southbridge) SCA/DPA ===
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.


==== Exploit Implementation ====
Side Channel Analysis (SCA) with Differential Power Analysis (DPA) on Aeolia and Belize (PS4 Southbridge revisions) has been shown to be able to recover key material. Since Sony never used private/public key pairs, it is possible to exploit this and gain complete control over the [[Southbridge]]. You can attack the main FreeBSD kernel from here.
* [https://twitter.com/theflow0/status/1717088032031982066 Removed 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 ====
Nearly same methods are working on recent PS4 Pro motherboard NVB-003 that has Belize [[Southbridge]] ([[CXD90046GG]]).
'''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.


=== FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW ===
Contrarly to Aeolia, Belize has ROM readout protection and clears stack which makes it more secure.


==== Credits ====
Old notes:
* CTurt for [https://github.com/CTurt/FreeDVDBoot FreeDVDBoot exploit on PS2] and the idea to hack BD-J on PS3 and PS4 [https://twitter.com/CTurtE/status/1276946283941498881 on twitter] (2020-06-27)
* TheFloW for finding these vulnerabilities (around 2021-10-24) and disclosing them publicly on hackerone and hardwear.io (2022-06-10)
* Sleirsgoevy for writing the first public implementation (2022-06-16)
* psxdev, sleirsgoevy and John Törnblom for the public implementations


==== Analysis ====
This is a 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. 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).
* [https://twitter.com/theflow0/status/1457362920501829636 TheFloW's PS5 kernel exploit announcement (2021-11-07)]
* [https://hackerone.com/reports/1379975 Official vulnerability report by TheFloW (2022-06-10)]
* [https://github.com/TheOfficialFloW/Presentations/blob/master/2022-hardwear-io-bd-jb.pdf Slides presented at hardwear.io by TheFloW (2022-06-10)]


==== Bug Description ====
Related:
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.
* [https://fail0verflow.com/blog/2018/ps4-aeolia/ fail0verflow's writeup]
* [https://twitter.com/fail0verflow/status/1047690778527653889 fail0verflow's tweet]
* [https://www.youtube.com/watch?v=sMroXa-zYxk Playstation 4 Rest Mode DEMO REcon Brussels 2018 by Volodymyr Pikhur]
* [https://recon.cx/2018/brussels/resources/slides/RECON-BRX-2018-Mess-with-the-best-die-like-the-rest_(mode).pdf Slides of REcon Brussels 2018 by Volodymyr Pikhur]
* [https://www.psxhax.com/threads/ps4-southbridge-reverse-engineered-code-examination-by-jogolden.6736/ jogolden's writeup]


TODO!: ADD DESCRIPTION OF EACH ONE OF THE 5 BUGS:
== Usermode Exploits (Game Savedata) ==


===== #1 - userprefs hijack (?PS3?, PS4, PS5) =====
=== PS2 games savedata exploits ===


com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl userprefs hijack leads to classes instantiation under privileged context.
==== GTA III ====


===== #2 - com.oracle.security.Service (?PS3?, PS4, not PS5) =====
* [https://github.com/halpz/re3/blob/9a7fa478578beaba947ea867c15a25e411d641d8/src/save/MemoryCard.cpp#L358 vulnerability]


com.oracle.security.Service leads to privileged constructor call.
The game does a copy from the memory card into a fixed-size buffer with size supplied by the savedata.


===== #3 - com.sony.gemstack.org.dvb.io.ixc.IxcProxy leading to privileged method call (?PS3?, PS4, PS5) =====
==== Dark Cloud ====


com.sony.gemstack.org.dvb.io.ixc.IxcProxy leads to privileged method call.
* [https://www.youtube.com/results?search_query=%22dark+cloud%22+item+glitch+menu+before%3A2008-01-01 video of bug triggering]


===== #4 - JIT compiler hack (?PS3?, PS4, not PS5) =====
Moving the cursor and pressing X on the same frame in the items menu allows us to pick up an item from out-of-bounds memory, which results in exploitable behaviour.


JIT compiler hack leads to usermode arbitrary RW and usermode arbitrary code execution.
==== Okage Shadow King ====


===== #5 - UDF buffer overflow (?PS3?, PS4, PS5) =====
===== Credits =====
 
* CTurt for discovering these vulnerabilities in September 2021.
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.
* CTurt for public disclosure [https://twitter.com/CTurtE/status/1570189920844804097 on twitter] https://twitter.com/CTurtE/status/1570189920844804097(2022-09-14)
 
* flatz, balika011, theflow0, chicken(s), PlayStation for helping CTurt
==== Exploit Implementation ====
* McCaulay for sharing publicly his implementation in February 2023.
* [https://github.com/TheOfficialFloW/bd-jb Implementation of BD-J usermode code execution on PS4 using bugs #1, #2, #3 and #4 by TheFloW (2021-10-24)]
* [https://github.com/TheOfficialFloW/bd-jb/blob/master/src/com/bdjb/exploit/sandbox/ExploitUserPrefsImpl.java Vuln #1 com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl implementation by TheFloW]
* [https://github.com/TheOfficialFloW/bd-jb/blob/master/src/com/bdjb/exploit/sandbox/ExploitServiceProxyImpl.java Vuln #2 com.oracle.security.Service and #3 com.sony.gemstack.org.dvb.io.ixc.IxcProxy chained together by TheFloW]
* [https://github.com/TheOfficialFloW/bd-jb/blob/master/src/com/bdjb/jit/JitCompilerReceiverImpl.java Vuln #4 JIT compiler hack implementation by TheFloW]
* [https://github.com/sleirsgoevy/bd-jb Implementation of BD-J usermode code execution on PS4 using bugs #2, #3 and #4 by sleirsgoevy (2022-06-16)]
* Note that no implementation of the UDF kernel exploit has ever been done even by TheFloW, only a kernel panic PoC.


==== Patched ====
===== Analysis =====
'''No''' as of PS4 FW 9.00 and PS5 FW 4.03. At least partially patched on PS4 FW 9.50 and PS5 FW 5.00.
* [https://mccaulay.co.uk/mast1c0re-part-1-modifying-ps2-game-save-files Writeup part 1 by McCaulay (2023-02-08)]
* [https://mccaulay.co.uk/mast1c0re-part-2-arbitrary-ps2-code-execution Writeup part 2 by McCaulay (2023-02-10)]


On PS4 FW 9.03 and PS5 FW ?4.50?, the bug #5 (UDF) has been patched.
===== Bug Description =====
Okage Shadow King has a typical stack buffer overflow if you extend the player or town name in a savedata.
* [https://store.playstation.com/en-us/product/UP9000-CUSA02199_00-SCUS971290000001 PS4 digital version CUSA02199 of SCUS97129 on PS Store]
Okage Shadow King for PS4 (CUSA02282) base version (1.00) requires FW version 3.15, although it was compiled with SDK version 3.008.000. Okage Shadow King for PS4 (CUSA02199 and CUSA02282) patch 1.01 requires FW version 4.05.


== Usermode Exploits (WebKit) ==
===== Exploit Implementation =====
* [https://github.com/McCaulay/okrager Okrager by McCaulay (2023-02-04)]


=== WebKit sources ===
===== Patched =====
'''No'''. Unpatchable in theory.


[https://doc.dl.playstation.net/doc/ps4-oss/webkit.html WebKit sources]
=== PS4/PS5 PS2emu sandbox escape (mast1c0re) ===


[https://web.archive.org/web/20241007081407/https://doc.dl.playstation.net/doc/ps4-oss/webkit.html WebKit sources] archived currently up to version 11.00. Useful for people that cannot access PlayStation URLs and also for when Sony will inevitably stop hosting the sources.
Advantages of the PS4/PS5 PS2emu sandbox escape exploit over most WebKit exploits:
 
* Bigger kernel attack surface (more usermode privileges) versus WebKit very restricted and becoming more and more with firmware revisions. For example, the PS2emu process uses libkernel_sys, which supports nmount and so mount of system partitions, whilst neither libkernel_web nor regular libkernel do.
=== FW ?6.00-11.52? - get_by_id_with_this associated with ProxyObject can leak JSScope objects ===
* 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions
* Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update


==== Credits ====
==== Credits ====
* Alexey Shvayka for discovery (2021-05-05) and incremental fixes (from 2021-05-20 to 2024-07-31)
* CTurt for discovering these vulnerabilities in September 2021.
* Filip Pizlo for reviewing and not pushing it (2021-06-10)
* CTurt for public disclosure [https://twitter.com/CTurtE/status/1570189920844804097 on twitter] (2022-09-14).
* Ahmad Saleem for reminding WebKit that it is still not fixed (2022-09-03)
* flatz, balika011, theflow0, chicken(s), PlayStation for helping CTurt.
* Yusuke Suzuki and Justin Michaud for fix commits review.
* McCaulay for sharing publicly his implementation in February 2023.


==== Analysis ====
==== Analysis ====
* [https://github.com/WebKit/WebKit/pull/35527 Fix commit #3 by Alexey Shvayka (2024-10-21)]
* [https://cturt.github.io/mast1c0re.html Writeup part 1 by CTurt (2022-09-14)]
* [https://github.com/WebKit/WebKit/pull/31572 Fix commit #2 by Alexey Shvayka (2024-07-31)]
* [https://mccaulay.co.uk/mast1c0re-part-3-escaping-the-emulator Writeup part 3 by McCaulay (2023-02-17)]
* [https://github.com/WebKit/WebKit/commit/ceb7e89febcd92b46d65396ce68e0d58ae6bcd6e Fix commit #1 for ProxyObject by Alexey Shvayka (2024-03-14)]
* [https://cturt.github.io/mast1c0re-2.html Writeup part 2 by CTurt (2023-04-02)]
* [https://github.com/WebKit/WebKit/blob/6bb75cf119f4cf3c077ec234af476fb575b28509/Source/WebCore/bindings/js/JSDOMOperation.h#L38 Workaround leftover by Alexey Shvayka (2021-05-20)]
* [https://github.com/WebKit/WebKit/commit/6bb75cf119f4cf3c077ec234af476fb575b28509 Incremental fix commit by Alexey Shvayka (2021-05-20)]
* [https://bugs.webkit.org/show_bug.cgi?id=225397 Bug report on WebKit Bugzilla by Alexey Shvayka (2021-05-05)]


==== Bug Description ====
==== Bug Description ====
* TODO: document the general vulnerability coming from |this|.
After getting code execution in a PS2onPS4 game using a savedata exploit, it is possible to exploit the PS2 emulator to get x86-64 usermode ROP execution. It is then possible, without a kernel exploit, to load another PS2 game in the emulator with a compatibility rate based on the PS2 emulator configuration.
 
According to the spec [1], `var base = { foo }; with (base) foo();` should be called with `this`
value of `base`, which is why FunctionCallResolveNode moves resolved scope to thisRegister().
That is arguably a bad design, and there is an effort [2] to abolish using JSScope as `this` value.
 
When `this` value is accessed by JS code, it's being sanitized via ToThis (JSScope replaced with
`undefined`), yet not in case of `super.property` access calling into ProxyObject `get` trap,
which passes raw `this` value as receiver parameter, leaking JSScope to be exploited.


==== Exploit Implementation ====
==== Exploit Implementation ====
* [https://github.com/shvaikalesh/WebKit/blob/ee167b8fe4fd234a33b2381640cba982fa6c7516/JSTests/stress/evaluate-with-scope-extension.js Stress code by Alexey Shvayka (2024-10-21)]
* [https://github.com/McCaulay/mast1c0re (2023-02-18)]
* [https://github.com/WebKit/WebKit/blob/ceb7e89febcd92b46d65396ce68e0d58ae6bcd6e/JSTests/stress/regress-120777816.js Regression test by Alexey Shvayka (2024-03-14)]


==== Patched ====
==== Patched ====
'''Maybe'''
'''No''' as of PS4 FW 11.00 and PS5 FW 8.00. Using the game Okage Shadow King, the exploit should work starting from PS4 FW 3.15 and PS5 FW 1.00.
 
== Usermode Exploits (BD-J) ==


==== Tested ====
Advantages of most BD-J exploits over most WebKit exploits:
Not tested yet on PS4 or PS5.
* Bigger kernel attack surface (more usermode privileges) versus WebKit very restricted and becoming more and more with firmware revisions. For example, the BD-J process uses libkernel_sys, which supports nmount and so mount of system partitions, whilst neither libkernel_web nor regular libkernel do.
----
* 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions
* Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update
* JIT enabled allowing to write a kernel exploit in C versus writing in assembly and JavaScript since around FW 2.00


=== FW ?6.00-11.52? - Integer underflow in JSC genericTypedArrayViewProtoFuncCopyWithin (CVE-2023-38600) ===
=== FW <= 10.71 - BD-JB2 - Path traversal sandbox escape by TheFloW ===


==== Credits ====
==== Credits ====
* anonymous researcher for discovering the vulnerability and reporting it to Zero Day Initiative (2023-05)
* TheFloW for the exploits finding (before 2023-09-11), ethical disclose to SCE (2023-09-22) and public disclosure (2023-10-25)
* Yusuke Suzuki and Mark Lam for fixing the bug in WebKit (2023-07-31)
* Previous BD-JB contributors
* Hossein Lotfi for publishing a writeup (2023-10-18)


==== Analysis ====
==== Analysis ====
* [https://www.zerodayinitiative.com/blog/2023/10/17/cve-2023-38600-story-of-an-innocent-apple-safari-copywithin-gone-way-outside Writeup by Hossein Lotfi (2023-10-18)]
* [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/WebKit/WebKit/commit/6e7e654417b61630d67f02b65798439cf3d6b0b5 WebKit fix commit by Yusuke Suzuki (2023-07-31)]


==== Bug Description ====
==== Bug Description ====
It is required to recompute length properly when resize happens during TypedArray copyWithin.
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.
 
copyWithin's side effectful operation can resize resizable ArrayBuffer. WebKit has a code catching this and recompute the appropriate copy count again, but it can overflow if `to` or `from` are larger than the newly updated `length`. The patch handles this case correctly: returning since there is no copying content in this case.
 
The issue was patched by aborting the copy if either of the two variables to or from is larger than the updated length.
 
The values used during the exploit were sane as they went through a sanitizer function. However, in the final stage, the values were updated without checking if there are inside the buffer length bounds.
 
According to PS4 WebKit source code for System Software version 11.00, not only it is not patched but it uses code from 2021! Looking at [https://github.com/WebKit/WebKit/blob/cccb58deac3c56a831678458ce95ea5b7c837614/Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h#L177 a version close to one in the PS4 source code for System Software version 11.00], it should be exploitable.


==== Exploit Implementation ====
==== Exploit Implementation ====
* [https://gist.github.com/zdi-team/ad320bdc6ad095cc210c7031e0f0ecda/raw/746ce622fe73344ccb9cd51bc03ad97950f4ea3b/CVE-2023-38600-0.js Minimal PoC by Hossein Lotfi (2023-10-18)]
* [https://twitter.com/theflow0/status/1717088032031982066 PoC by TheFloW (2023-10-25)]
* [https://github.com/WebKit/WebKit/blob/main/JSTests/stress/resizable-array-buffer-copy-within-length-update.js Vulnerability test code by Yusuke Suzuki (2023-07-31)]


==== Patched ====
==== Patched ====
'''Maybe''' in FW 11.50.
'''No''' as of PS4 FW 10.71 (maybe patched on PS4 FW 11.00). '''Yes''' on PS5 FW 8.00.


==== Tested ====
=== FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW ===
Not tested yet on PS4 nor PS5. To test on PS4 11.00.
----
 
=== FW ?6.00-11.00? - CloneDeserializer::deserialize() UaF (CVE-2023-28205) leading to arbitrary RW ===


==== Credits ====
==== Credits ====
* Clément Lecigne of Google's Threat Analysis Group and Donncha Ó Cearbhaill of Amnesty International’s Security Lab for discovering the vulnerability and reporting it to Apple (2023-04-10)
* CTurt for [https://github.com/CTurt/FreeDVDBoot FreeDVDBoot exploit on PS2] and the idea to hack BD-J on PS3 and PS4 [https://twitter.com/CTurtE/status/1276946283941498881 on twitter] (2020-06-27)
* Justin Michaud, Mark Lam and JonWBedard for fixing the bug in WebKit (2023-04-17)
* TheFloW for finding these vulnerabilities (around 2021-10-24) and disclosing them publicly on hackerone and hardwear.io (2022-06-10)
* abc (anonymous) for making an OOM PoC for PS4 and PS5 (2024-12-01)
* Sleirsgoevy for writing the first public implementation (2022-06-16)
* psxdev, sleirsgoevy and John Törnblom for the public implementations


==== Analysis ====
==== Analysis ====
* [https://github.com/WebKit/WebKit/commit/c9880de4a28b9a64a5e1d0513dc245d61a2e6ddb WebKit fix commit (2023-04-17)]
* [https://twitter.com/theflow0/status/1457362920501829636 TheFloW's PS5 kernel exploit announcement (2021-11-07)]
* [https://hackerone.com/reports/1379975 Official vulnerability report by TheFloW (2022-06-10)]
* [https://github.com/TheOfficialFloW/Presentations/blob/master/2022-hardwear-io-bd-jb.pdf Slides presented at hardwear.io by TheFloW (2022-06-10)]


==== Bug Description ====
==== Bug Description ====
Previously, CloneDeserializer::deserialize() was storing pointers to newly created objects in a few Vectors, in a MarkedArgumentBufferBase. This is problematic because the GC is not aware of Vectors, and cannot scan them. Instead, CloneDeserializer::deserialize() should store cell pointers in a MarkedVector.
TO ADD DESCRIPTION OF EACH ONE OF THE 5 BUGS:


The PoC code triggers a use-after-free (UaF) vulnerability by delaying the addition of Map and Date objects, which allows the garbage collector (GC) to free them. This can potentially lead to accessing freed objects to corrupt memory. Then it cannot avoid executing a release assert that causes an Out-Of-Memory crash.
* #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)


The WebKit patch refactors the MarkedArgumentBuffer class into a MarkedVector template class.
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.


==== Exploit Implementation ====
==== Exploit Implementation ====
* [https://github.com/ntfargo/uaf-2023-28205/blob/main/poc.js PoC by abc (2024-12-01)]
* [https://github.com/TheOfficialFloW/bd-jb Implementation of BD-J usermode code execution on PS4 using bugs #1, #2, #3 and #4 by TheFloW (2021-10-24)]
* [https://github.com/TheOfficialFloW/bd-jb/blob/master/src/com/bdjb/exploit/sandbox/ExploitUserPrefsImpl.java Vuln #1 com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl implementation by TheFloW]
* [https://github.com/TheOfficialFloW/bd-jb/blob/master/src/com/bdjb/exploit/sandbox/ExploitServiceProxyImpl.java Vuln #2 com.oracle.security.Service and #3 com.sony.gemstack.org.dvb.io.ixc.IxcProxy chained together by TheFloW]
* [https://github.com/TheOfficialFloW/bd-jb/blob/master/src/com/bdjb/jit/JitCompilerReceiverImpl.java Vuln #4 JIT compiler hack implementation by TheFloW]
* [https://github.com/sleirsgoevy/bd-jb Implementation of BD-J usermode code execution on PS4 using bugs #2, #3 and #4 by sleirsgoevy (2022-06-16)]
* Note that no implementation of the UDF kernel exploit has ever been done even by TheFloW, only a kernel panic PoC.


==== Patched ====
==== Patched ====
'''Yes''' on PS4 FW ?11.00? and PS5 FW ?8.00?.
'''No''' as of PS4 FW 9.00 and PS5 FW 4.03. At least partially patched on PS4 FW 9.50 and PS5 FW 5.00.
 
On PS4 FW 9.03 and PS5 FW ?4.50?, the bug #5 (UDF) has been patched.
 
== Usermode Exploits (WebKit) ==


==== Tested ====
=== WebKit sources ===
Tested working on PS4 FWs ? and PS5 FWs 6.00-7.61.
[https://web.archive.org/web/20231108165430/https://doc.dl.playstation.net/doc/ps4-oss/webkit.html WebKit sources] Currently archived up to version 10.01. Useful for developers that can't access PlayStation URLs and also for when Sony inevitably stops hosting the sources in the future.
----


=== FW 6.00-9.60 - FrameLoader::loadInSameDocument() UaF (CVE-2022-22620) leading to arbitrary RW ===
=== FW 6.00-9.60 - FrameLoader::loadInSameDocument() UaF (CVE-2022-22620) leading to arbitrary RW ===
Line 301: Line 238:
* Sergei Glazunov, Google Project Zero, for reporting the bug in 2013-01 and answering Maddie Stone's questions in 2022 (2013)
* Sergei Glazunov, Google Project Zero, for reporting the bug in 2013-01 and answering Maddie Stone's questions in 2022 (2013)
* Maddie Stone, Google Project Zero, for sharing a write-up describing this vulnerability (2022-06-14)
* Maddie Stone, Google Project Zero, for sharing a write-up describing this vulnerability (2022-06-14)
* abc (anonymous) for making an OOM PoC for webkit-gtk, PS4 and PS5 (2023-10-03) then making an arbitrary RW PoC (PSFree) for webkit-gtk, PS4 6.00-9.60 and PS5 1.00-5.50 (2023-10-24)
* Anonymous for making an OOM PoC for webkit-gtk, PS4 and PS5 (2023-10-03) then making an arbitrary RW PoC (PSFree) for webkit-gtk, PS4 6.00-9.60 and PS5 1.00-5.50 (2023-10-24)
* CelesteBlue for testing and porting abc' PSFree to PS4 6.00-9.60 and PS5 1.00-5.50 (2023-11-04)
* CelesteBlue for testing and porting anonymous' PSFree to PS4 6.00-9.60 and PS5 1.00-5.50 (2023-11-04)


==== Analysis ====
==== Analysis ====
Line 356: Line 293:
* Simple PoC for ASAN webkit-gtk by Maddie Stone in Maddie Stone's writeups
* Simple PoC for ASAN webkit-gtk by Maddie Stone in Maddie Stone's writeups
* [https://github.com/springsec/CVE-2022-22620/blob/main/CVE-2022-22620_infoleak_exploit.html Information leak PoC for webkit-gtk by springsec]
* [https://github.com/springsec/CVE-2022-22620/blob/main/CVE-2022-22620_infoleak_exploit.html Information leak PoC for webkit-gtk by springsec]
* [https://discord.com OOM PoC for PS4 and PS5 by abc on ps4-dev discord (to mirror)]
* [https://discord.com OOM PoC for PS4 and PS5 by anonymous on ps4-dev discord (to mirror)]
* [https://discord.com Arbitrary RW PoC (PSFree) for PS4 6.00-9.60 and PS5 1.00-5.50 by abc on ps4-dev discord (to mirror)]
* [https://discord.com Arbitrary RW PoC (PSFree) for PS4 6.00-9.60 and PS5 1.00-5.50 by anonymous on ps4-dev discord (to mirror)]


==== Patched ====
==== Patched ====
Line 364: Line 301:
The patch changes the stateObject argument to loadInSameDocument from a raw pointer, SerializedScriptValue*, to a reference-counted pointer, RefPtr<SerializedScriptValue>, so that loadInSameDocument now increments the reference count on the object.
The patch changes the stateObject argument to loadInSameDocument from a raw pointer, SerializedScriptValue*, to a reference-counted pointer, RefPtr<SerializedScriptValue>, so that loadInSameDocument now increments the reference count on the object.


==== Tested ====
Tested working on PS4 FWs 6.00-9.60 and PS5 FWs 1.00-5.50. PS4 FWs <= 5.56 are invulnerable as the HTML input field stays focused (blue outline) after second timeout whilst it should not if the console were exploitable.
Tested working on PS4 FWs 6.00-9.60 and PS5 FWs 1.00-5.50. PS4 FWs <= 5.56 are invulnerable as the HTML input field stays focused (blue outline) after second timeout whilst it should not if the console were exploitable.
----


=== FW 9.00-9.04 - WebCore::CSSFontFaceSet vulnerabilities leading to arbitrary RW ===
=== FW 9.00-9.04 - WebCore::CSSFontFaceSet vulnerabilities leading to arbitrary RW ===
Line 389: Line 324:
* [https://github.com/WebKit/WebKit/commit/fbf37d27e313d8d0a150a74cc8fab956eb7f3c59 WebKit fix commit by Myles C. Maxfield merged by Russell Epstein (2021-09-09)]
* [https://github.com/WebKit/WebKit/commit/fbf37d27e313d8d0a150a74cc8fab956eb7f3c59 WebKit fix commit by Myles C. Maxfield merged by Russell Epstein (2021-09-09)]
* [https://github.com/WebKit/WebKit/blob/74bd0da94fa1d31a115bc4ee0e3927d8b2ea571e/Source/WebCore/css/CSSFontFaceSet.cpp#L223 Part of vulnerable code]
* [https://github.com/WebKit/WebKit/blob/74bd0da94fa1d31a115bc4ee0e3927d8b2ea571e/Source/WebCore/css/CSSFontFaceSet.cpp#L223 Part of vulnerable code]
* [https://web.archive.org/web/20211020134808/https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html (archive) Write-up and PoC by Maddie Stone (2021-10-13)]. Maddie Stone's vulnerability is not CVE-2021-30858 but instead might be CVE-2021-30889. See [https://github.com/googleprojectzero/0days-in-the-wild/commit/65fcdf0473ada4e80dc967662ea8f3f3ce4ea81e#diff-1a428c43cedcf140e5bd6f92e4527f169c3c717780e1586f2fab589e4f467b52 write-up edit commit]. Warning: Maddie Stone's vulnerability was wrongly classified as a use-after-free by Maddie Stone according to sleirsgoevy.
* [https://web.archive.org/web/20211020134808/https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html (archive) Write-up and PoC by Maddie Stone (2021-10-13)]. Maddie Stone's vulnerability is not CVE-2021-30858 but was guessed to be by Maddie Stone. See [https://github.com/googleprojectzero/0days-in-the-wild/commit/65fcdf0473ada4e80dc967662ea8f3f3ce4ea81e#diff-1a428c43cedcf140e5bd6f92e4527f169c3c717780e1586f2fab589e4f467b52 write-up edit commit]. Warning: Maddie Stone's vulnerability was wrongly classified as a use-after-free by Maddie Stone according to sleirsgoevy.
* [https://wololo.net/2021/10/14/use-after-free-webkit-vulnerability-impacts-ps4-possibly-up-to-firmware-9-00-included/ Vulnerability description by Wololo (2021-10-14)]
* [https://wololo.net/2021/10/14/use-after-free-webkit-vulnerability-impacts-ps4-possibly-up-to-firmware-9-00-included/ Vulnerability description by Wololo (2021-10-14)]


Line 395: Line 330:
Description in WebKit fix commit by Myles C. Maxfield:
Description in WebKit fix commit by Myles C. Maxfield:


After r256659, asking for a failed CSSFontFace's families() returns nullopt. It is possible to add a failed font to a CSSFontFaceSet (of course). When we do that, we recognize the font is failed and do not update our internal data structures, because there's no need to - we cannot do anything useful with a failed font. If you _then_ try to remove the font from the CSSFontFace, we do not call families(), but instead just pull out the raw m_families member, and look in our internal data structures for it, but we do not find it, because it was never added.
After r256659, asking for a failed CSSFontFace's families() returns nullopt. It's possible to add a failed font to a CSSFontFaceSet (of course). When we do that, we recognize the font is failed and do not update our internal data structures, because there's no need to - we cannot do anything useful with a failed font. If you _then_ try to remove the font from the CSSFontFace, we do not call families(), but instead just pull out the raw m_families member, and look in our internal data structures for it, but we do not find it, because it was never added.


Description in Maddie Stone's write-up:
Description in Maddie Stone's write-up:
Line 407: Line 342:
==== Exploit Implementation ====
==== Exploit Implementation ====
* [https://web.archive.org/web/20211024215236/http://vdsina.sleirsgoevy.dynv6.net:8081/ (archive) First exploit PoC for Safari by sleirsgoevy (2021-10-24)]
* [https://web.archive.org/web/20211024215236/http://vdsina.sleirsgoevy.dynv6.net:8081/ (archive) First exploit PoC for Safari by sleirsgoevy (2021-10-24)]
* [https://gist.github.com/sleirsgoevy/6beca32893909095f4bba1ce29167992 First exploit PoC for PS4 FW 9.00-9.04 and PS5 FW 3.00-4.51 by sleirsgoevy (2021-10-27)]
* [https://gist.github.com/sleirsgoevy/6beca32893909095f4bba1ce29167992 First exploit PoC for PS4 FW 9.00-9.04 and PS5 FW 3.00-4.50 by sleirsgoevy (2021-10-27)]
* [https://github.com/ChendoChap/pOOBs4/blob/main/webkit.js Implementation for PS4 FW 9.00 with exFAT kernel exploit in pOOBs4 by ChendoChap (2022-01-17)]
* [https://github.com/ChendoChap/pOOBs4/blob/main/webkit.js Implementation for PS4 FW 9.00 with exFAT kernel exploit in pOOBs4 by ChendoChap (2022-01-17)]


==== Patched ====
==== Patched ====
'''Yes''' on PS4 FW 9.50 and '''No''' as of PS5 FW 4.51 (need to test on PS5 FWs >=5.00). Not working on PS4 FWs <9.00 and PS5 FWs <2.10.
'''Yes''' on PS4 FW 9.50 and '''No''' as of PS5 FW 4.50.


Might have been introduced in PS4 FW 3.50 and before PS5 FW 1.00 according to dates (need to check). However the vulnerability cannot be exploited in some conditions depending on how WebKit was compiled. For example, on PS4 FWs 7.55-8.52 and PS5 FWs <= 2.00, the FontFaceSet constructor returns with an exception that is propagated to JavaScript, preventing exploitation this way.
Might have been introduced in PS4 FW 3.50 and before PS5 FW 1.00 according to dates (need to check). However the vulnerability cannot be exploited in some conditions depending on how WebKit was compiled. For example, on PS4 FWs 7.55-8.53 and PS5 FWs <= 2.00, the FontFaceSet constructor returns with an exception that is propagated to JavaScript, preventing exploitation this way.


==== Tested ====
Tested working on PS4 FWs 9.00-9.04 and PS5 FWs 3.00-4.50. Untested: PS5 FWs 2.10-2.50, 4.51.
Tested working on PS4 FWs 9.00-9.04 and PS5 FWs 3.00-4.51. Untested: PS5 FWs 2.10-2.70 and >=5.00.
----


=== FW 6.00-7.55 - WebCore::ValidationMessage::buildBubbleTree() UaF leading to arbitrary RW ===
=== FW 6.00-7.55 - WebCore::ValidationMessage::buildBubbleTree() UaF leading to arbitrary RW ===
Line 445: Line 378:


==== Patched ====
==== Patched ====
'''Yes''' in 8.00 FW.
'''Yes''' in 8.00 FW. Tested working on FWs 6.00-7.55, not working on FWs <= 5.56. HTML textarea guessed addresses for FWs 6.70-7.55 are known but not for FWs 6.00-6.51 so an attacker needs to make tests to determine these addresses on FWs 6.00-6.51.
 
==== Tested ====
Tested working on FWs 6.00-7.55, not working on FWs <= 5.56. HTML textarea guessed addresses for FWs 6.70-7.55 are known but not for FWs 6.00-6.51 so an attacker needs to make tests to determine these addresses on FWs 6.00-6.51.
----


=== FW 6.00-6.72 - bad_hoist Type Confusion exploit (CVE-2018-4386) leading to arbirary RW ===
=== FW 6.00-6.72 - bad_hoist Type Confusion exploit (CVE-2018-4386) leading to arbirary RW ===
Line 492: Line 421:


==== Patched ====
==== Patched ====
'''Yes''' in 7.00 FW.
'''Yes''' in 7.00 FW. Vulnerable on PS4 FWs 4.50-6.72. Not vulnerable on FWs <= 4.07. Not vulnerable on FWs >=7.00 according to manual tests but need to check WebKit sources.
 
==== Tested ====
Vulnerable on PS4 FWs 4.50-6.72. Not vulnerable on FWs <= 4.07. Not vulnerable on FWs >=7.00 according to manual tests but need to check WebKit sources.
----
----


Line 518: Line 444:


==== Patched ====
==== Patched ====
'''Yes''' in 6.50 FW.
'''Yes''' in 6.50 FW. It does not work on <= 4.07 FW PS4 according to tests as the exploit fails at step "Triggering memory corruption".
 
==== Tested ====
It does not work on <= 4.07 FW PS4 according to tests as the exploit fails at step "Triggering memory corruption".
----
----


Line 662: Line 585:
==== Tested ====
==== Tested ====
Works on 3.15-4.07. Not working on <= 3.11.
Works on 3.15-4.07. Not working on <= 3.11.
----
=== FW <= ?4.05? - Type confusion in WebCore::HTMLInputElement::onSearch (CVE-2017-2354) ===
==== Credits ====
* Neymar of Tencent's Xuanwu Lab working with Trend Micro's Zero Day Initiative for discovering this vulnerability (2016-11)
* Brent Fulgham for fixing the bug in WebKit (2016-11-14)
* Jasiel Spelman (@WanderingGlitch) for his writeup (2017-12-20)
==== Analysis ====
* [https://www.zerodayinitiative.com/blog/2017/12/20/invariantly-exploitable-input-an-apple-safari-bug-worth-revisiting Writeup by Jasiel Spelman (2017-12-20)]
* [https://github.com/WebKit/WebKit-http/commit/cf2bf6e58f51267d7ae25fcb82a315377c8e5cf6 WebKit fix commit by Brent Fulgham (2016-11-14)]
==== Bug Description ====
It is possible for JavaScript to change the type property of an input field. WebKit needs to gracefully handle this case.
This bug could have been prevented had it a debug check been used instead of a runtime check. In fact, WebKit has support for this type of assertion already through a RELEASE_ASSERT macro, which would have turned this exploitable bug into a simple denial-of-service by immediately and safely crashing the browser.
The fix commit of the vulnerability adds a type traits specialization so that WebKit can properly downcast InputType elements. This should be used only to call search functions on actual search input types.
Although the access violation in WebCore::TimerBase::heapPop is where we see the result of the bug, it is not the cause of the issue. The crash actually occurs as a result of reading a pointer that comes from the 'this' object. Based on that, it would seem that something is wrong with the Timer object passed into the WebCore::TimerBase::heapPop function.
This vulnerability may be the one used by Chaintin Tech with a kernel exploit on PS4 FW 4.01 at GeekPwn 2016, a Tencent Security's conference, in Shanghai Station at the Pavilion Safety Research Lab, (https://www.chaitin.cn/ps4, https://www.psxhax.com/threads/ps4-4-01-linux-installation-ksploit-demo-at-geekpwn-2016.932/)
==== Exploit Implementation ====
* PoC by Neymar (2016-11, disclosed publicly by Jasiel Spelman on 2017-12-20):
<source lang="js">
<input id="m_input" type="search"></input>
<script type="text/javascript">
first = true;
m_input.addEventListener("input", function (e) {
if(first) {
first = false;
}
else {
m_input["type"] = "image";
}
}, false);
</script>
</source>
* [https://github.com/WebKit/WebKit-http/blob/master/LayoutTests/fast/forms/search-cancel-button-change-input.html Vulnerability test by Brent Fulgham (2016-11-15)]
==== Patched ====
'''Maybe''' in 4.06 FW
==== Tested ====
Not yet.
----
----


Line 719: Line 595:


==== Analysis ====
==== Analysis ====
* [https://blog.xyz.is/2016/webkit-360.html PSVita 3.60 HENkaku WebKit exploit writeup]
* [https://blog.xyz.is/2016/webkit-360.html PSVita 3.60 HENKaku WebKit exploit writeup]


==== Bug Description ====
==== Bug Description ====
Line 737: Line 613:


=== FW <= 3.50 - WebCore::TimerBase::heapPopMin() Heap UaF leading to crash ===
=== FW <= 3.50 - WebCore::TimerBase::heapPopMin() Heap UaF leading to crash ===
==== Credits ====
* Brent Fulgham for fixing the bug in WebKit (2016-05-16)


==== Analysis ====
==== Analysis ====
* [https://github.com/WebKit/WebKit-http/commit/98845d940e30529098eea7e496af02e14301c704 WebKit fix commit (2016-05-17)]
* [https://github.com/WebKit/WebKit-http/commit/98845d940e30529098eea7e496af02e14301c704 WebKit fix commit (17-05-2016)]
* [https://xz.aliyun.com/t/292 Summary of Critical and Exploitable iOS Vulnerabilities in 2016 by Min (Spark) Zheng, Cererdlong, Eakerqiu @ Team OverSky]
* [https://xz.aliyun.com/t/292 Summary of Critical and Exploitable iOS Vulnerabilities in 2016 by Min (Spark) Zheng, Cererdlong, Eakerqiu @ Team OverSky]


Line 749: Line 622:


==== Exploit Implementation ====
==== Exploit Implementation ====
* [http://psxhax.com/threads/ps4-3-50-webkit-exploit-from-playstation-4-dev-qwertyoruiop.450/ Article about qwertyoruiop's tests (2016-05-20)]
* [http://psxhax.com/threads/ps4-3-50-webkit-exploit-from-playstation-4-dev-qwertyoruiop.450/ Article about qwertyoruiop's tests (20-05-2016)]
* [http://psxhax.com/threads/ps4-heap-use-after-free-at-webcore-3-50-poc-by-hunter128.452/ Article about initial PoC for PS4 (2016-05-21)]
* [http://psxhax.com/threads/ps4-heap-use-after-free-at-webcore-3-50-poc-by-hunter128.452/ Article about initial PoC for PS4 (21-05-2016)]
* [http://wololo.net/talk/viewtopic.php?t=45888 Initial PoC for PS4 (2016-05-21)]
* [http://wololo.net/talk/viewtopic.php?t=45888 Initial PoC for PS4 (21-05-2016)]
* [https://web.archive.org/web/20161030085033/http://cryptoanarchic.me/wat.txt iOS 9.3.2 WebKit RCE via heapPopMin (2016-07)]
* [https://web.archive.org/web/20161030085033/http://cryptoanarchic.me/wat.txt iOS 9.3.2 WebKit RCE via heapPopMin (07-2016)]
* [https://twitter.com/qwertyoruiopz/status/756268361282125824 qwertyoruiop's tweet (2016-07-22)]
* [https://twitter.com/qwertyoruiopz/status/756268361282125824 qwertyoruiop's tweet (22-07-2016)]
* [https://github.com/Jailbreaks/jbme/tree/master mirror of iOS 9.3.2 WebKit RCE via heapPopMin]
* [https://github.com/Jailbreaks/jbme/tree/master mirror of iOS 9.3.2 WebKit RCE via heapPopMin]


Line 761: Line 634:
==== Tested ====
==== Tested ====
Works on 3.15, 3.50 FW. Maybe working on 3.51 FW.
Works on 3.15, 3.50 FW. Maybe working on 3.51 FW.
----
=== FW <= ?2.50? - JavaScript OnLoad Handler Remote Code Execution Vulnerability (CVE-2005-1790) leading to crash or lag ===
==== Credits ====
* Benjamin Tobias Franz for the vulnerability discovery (2005-11-21)
* Stuart Pearson for the Proof of Concept on Microsoft Internet Explorer
* Sam Sharps for the Metasploit port (2012-01)
* Jeerum for disclosing that the vulnerability affects PS4 <=2.50 (2014-10-31).
==== Analysis ====
* [https://web.archive.org/web/20150617052519/http://sebug.net:80/paper/Exploits-Archives/2012-exploits/1201-exploits/ms05_054_onload.rb.txt Metasploit file by Sam Sharps (2012-01)]
* [https://malware.wicar.org/data/ms05_054_onload.html PoC by wicar.org (before 2012-11-10)]
* [https://wololo.net/talk/viewtopic.php?f=63&t=40446 PoC for PS4 by Jeerum (2014-10-31)]
* [https://www.youtube.com/watch?v=J_-1nyfCo84 PS4 4.55 test of 1js by Jeerum]
==== Bug Description ====
This bug is triggered when the browser handles a JavaScript 'onLoad' handler in conjunction with an improperly initialized 'window()' JavaScript function. This exploit results in a call to an address lower than the heap. The javascript prompt() places our shellcode near where the call operand points to. We call prompt() multiple times in separate iframes to place our return address. We hide the prompts in a popup window behind the main window. We spray the heap a second time with our shellcode and point the return address to the heap. I use a fairly high address to make this exploit more reliable. Microsoft Internet Explorer will crash when the exploit completes. Also, please note that Microsoft Internet Explorer must allow popups in order to continue exploitation.
==== Exploit Implementation ====
==== Patched ====
'''Maybe'''
==== Tested ====
* Working on 1.76-2.50 FW: crash. 3.00-5.50 error CE-36329-3. 4.55 lag in background TV application (for example Netflix application).
----
----


Line 862: Line 709:


* Vitaliy Toropov for the exploit on Mac OS X Safari (September 4, 2013)
* Vitaliy Toropov for the exploit on Mac OS X Safari (September 4, 2013)
* nas and Proxima for the first PS4 POC on 1.76 PS4 (October 23, 2014)
* nas and Proxima for the first PS4 POC on 1.76 PS4 (Oct. 23, 2014)
* sony for patching the exploit in FW 2.00 (October 27, 2014)
* sony for patching the exploit in FW 2.00 (Oct 27, 2014)
* CTurt for the rewriting (PS4 1.76 PlayGround) and implementation with his 1.76 kexploit (December 6, 2015) [https://twitter.com/CTurtE/status/673581693207502849]
* CTurt for the rewriting (PS4 1.76 PlayGround) and implementation with his 1.76 kexploit (December 6, 2015) [https://twitter.com/CTurtE/status/673581693207502849]


Line 887: Line 734:


==== Tested ====
==== Tested ====
* Working on PS4 1.00-1.76 FW, AppleWebKit/531.3-536.26
* Working on 1.00-1.76 FW, AppleWebKit/531.3-536.26
* Might work on PS4 FW 0.930.020.
* Might work on FW 0.930.020.
 
=== Possible WebKit vulnerabilities ===
 
<pre>
CVE-2017-7064
https://project-zero.issues.chromium.org/issues/42450258
 
CVE-2018-4192
https://blog.ret2.io/2018/06/13/pwn2own-2018-vulnerability-discovery/
https://blog.ret2.io/2018/06/19/pwn2own-2018-root-cause-analysis/#arrayreverse-considered-harmful
https://blog.ret2.io/2018/07/11/pwn2own-2018-jsc-exploit/
 
CVE-2018-4443
WebKit JSC - 'AbstractValue::set' Use-After-Free
lokihardt of Google Project Zero
2019-01-22
https://www.exploit-db.com/exploits/46071
 
Improper Restriction of Operations within the Bounds of a Memory Buffer
 
Unknown CVE
Luca Todesco (qwertyruiopz)
before 2019-08-15
https://gist.github.com/jakeajames/5ceb90ebaa34eabb3e170b5c7eb2c7d1/revisions
</pre>
 
=== Resources for WebKit exploitation ===
 
https://webkit.org/blog/12967/understanding-gc-in-jsc-from-scratch/
 
https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html


== Usermode securities ==
== Usermode securities ==
Line 930: Line 746:
=== Module imports table cleaned before execution ===
=== Module imports table cleaned before execution ===


* Between 1.76 and 4.05, Sony did that to prevent WebKit exploiters from defeating usermode ASLR easily.
* Between 1.76 and 4.05, Sony did that to prevent webkit exploiters from defeating usermode ASLR easily.
* Now we have to dump entire usermode sandboxed memory, and by studying it we can defeat ASLR:
* Now we have to dump entire usermode sandboxed memory, and by studying it we can defeat ASLR:
1. Chose a function (ex: __stack_chk_fail) imported from libkernel.sprx by libSceWebkit2.sprx
1. Chose a function (ex: __stack_chk_fail) imported from libkernel.sprx by libSceWebkit2.sprx
Line 943: Line 759:


=== DEP / NX ===
=== DEP / NX ===
* "Data Execution Prevention" / "No eXecute" is enabled on all firmwares. It prevents allocating memory as both RW and RX at same time (RWX) so preventing us from writing shellcode to usermode memory then executing it.
* "Data Execution Prevention" / "No eXecute" is enabled on all firmwares. It prevents allocating memory as both RW and RX at same time (RWX) so preventing us from writing shellcode to usermode memory then executing it.
* 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs).
* 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs).


=== JiT removed from webbrowser ===
=== JiT removed from webbrowser ===
* On FW <= 1.76, you could map RWX memory from ROP by abusing the JiT functionality and the sys_jitshm_create and sys_jitshm_alias system calls. This however was fixed after 1.76, as WebKit has been split into two processes. One handles javascript compilation and the other handles other web page elements like image rendering and DOM. The second process will request JiT memory upon hitting JavaScript via IPC (Inter-Process Communication). Since we no longer have access to the process responsible for JiT, we can no longer (at least currently), map RWX memory for proper code execution unless the kernel is patched.
* On FW <= 1.76, you could map RWX memory from ROP by abusing the JiT functionality and the sys_jitshm_create and sys_jitshm_alias system calls. This however was fixed after 1.76, as WebKit has been split into two processes. One handles javascript compilation and the other handles other web page elements like image rendering and DOM. The second process will request JiT memory upon hitting JavaScript via IPC (Inter-Process Communication). Since we no longer have access to the process responsible for JiT, we can no longer (at least currently), map RWX memory for proper code execution unless the kernel is patched.
* Checking the source code at [https://doc.dl.playstation.net/doc/ps4-oss/webkit.html ps4-oss], starting as early as FW 6.00, ENABLE_JIT=OFF for -DPORT=PlayStation4. It means that JIT functionality is completely removed from WebKit and there is no JIT coprocess that is allowed to request RWX memory to even attack. Even if there are JIT bugs that can lead us to request RWX memory in other platforms, we can't on the PS4 as there is no longer any JIT process. Unchecked all source codes, JIT process could have been removed earlier than 6.00. All exploits must use ROP.
* Checking the source code at [https://doc.dl.playstation.net/doc/ps4-oss/webkit.html ps4-oss], starting as early as FW 6.00, ENABLE_JIT=OFF for -DPORT=PlayStation4. It means that JIT functionality is completely removed from WebKit and there is no JIT coprocess that is allowed to request RWX memory to even attack. Even if there are JIT bugs that can lead us to request RWX memory in other platforms, we can't on the PS4 as there is no longer any JIT process. Unchecked all source codes, JIT process could have been removed earlier than 6.00. All exploits must use ROP.
Line 955: Line 769:
=== Syscalls removed ===
=== Syscalls removed ===


* See the PS4 [[Syscalls]] list.
=== Syscall 0 disabled i.e Error Kernel: The application directly issues a syscall instruction (24) ===
 
=== Direct Syscall invocation disabled in PS4 Kernel ===
 
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 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 Instruction Pointer (IP) must follow the syscall stub format,
* 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)".
 
An attacker is now forced to use wrappers provided from the libkernel / libkernel_web / libkernel_sys modules to trigger 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.
* Between 2.00 and 2.57, SCE has removed system call 0, so we can no longer call any syscall we want by specifying the call number in the rax register.
* 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)".
* We now have to use wrappers provided to us from the libkernel / libkernel_web / libkernel_sys modules to access system calls.


=== bpf_write function stripped out of the kernel ===
=== bpf_write function stripped out of the kernel ===
Line 975: Line 780:


=== bpf_open function blocked for unprivileged processes ===
=== bpf_open function blocked for unprivileged processes ===
* On 5.50, opening BPF has been blocked for unprivileged processes such as WebKit and other apps/games. It's still present in the sandbox, however attempting to open it will fail and yield EPERM. This aims blocking BPF kernel exploits especially qwertyoruiop's BPF double free UAF.
* On 5.50, opening BPF has been blocked for unprivileged processes such as WebKit and other apps/games. It's still present in the sandbox, however attempting to open it will fail and yield EPERM. This aims blocking BPF kernel exploits especially qwertyoruiop's BPF double free UAF.


=== bpf_ioctl function blocked or removed ===
=== bpf_ioctl function blocked or removed ===
 
* Moreover, on FW 5.50+, opening BPF is still possible in less sandboxed apps like test/devkits fselfs. But this is useless because ioctl does not work.
* On FW 5.50+, opening BPF is still possible in less sandboxed apps like TestKit/DevKits fSELFs. But this is useless because ioctl does not work.


=== Device access blocked/removed from webbrowser ===
=== Device access blocked/removed from webbrowser ===


* Around 6.50-6.70, device access got blocked or removed. Now you can no longer access devices from the web browser.
* Around 6.50-6.70, device access got blocked or removed. Now you can no longer access devices from webbrowser


=== Pointer poisoning in WebKit on 6.xx firmwares ===
=== WebKit implements pointer poisoning for 6.xx firmwares ===


* For select types implemented by WebKit (such as JSC::JSFunction), certain pointer fields are XOR'ed by a cryptographic key generated at runtime. The key is generated once every process launch, one must recover it to unpoison the pointers.
* For select types implemented by WebKit (such as JSC::JSFunction), certain pointer fields are XOR'ed by a cryptographic key generated at runtime. The key is generated once every process launch, one must recover it to unpoison the pointers.


=== Flush-to-Zero and Denormals-are-Zero Floating-Point environment ===
== Kernel Exploits ==
 
[https://en.wikipedia.org/wiki/Subnormal_number Subnormal numbers] (also called as denormal numbers in IEEE 754 documents before the 2008 version) are treated as 0 on the PlayStation runtime environment. This isn't technically a security technique but it does inhibit any exploit that uses floating-point numbers for read/write.
 
An example entrypoint is WebKit where exploits have commonly used double arrays with incorrect length to read/write certain memory areas to gain arbitrary read/write or even code execution. With FTZ/DAZ, the possible 64-bit values one can write have become even more limited. Reads using double arrays are also affected. Even if the bit pattern is nonzero but encodes a subnormal, it will be read by the JavaScript engine as 0.
 
== Kernel ==
 
=== FW <= 11.52 - Double free in bnet_netevent_set_queue ===
 
==== Credits ====
* Anonymous for sharing 11.52 and 12.00 PS4 kernel dumps.
* 2024-09-27 D-Link Turtle for diffing 11.52 and 12.00 PS4 kernel dumps.
* 2024-10-04 SlidyBat for figuring out the bug in bnet and its impact.
 
==== Analysis ====
* [https://x.com/iMrDJAi/status/1842306232125964473/photo/1 Analysis by abc (2024-10-04)]
 
==== Bug Description ====
A double free can happen by racing calls to bnet_netevent_set_queue and bnet_netevent_unset_queue.
 
The lack of mutexes allowed double free as fdrop is called unconditionally in bnet_netevent_unset_queue.
 
See also PS Vita SceNetPs kernel module that uses similar bnet functions.
 
==== Exploit Implementation ====
 
==== Patched ====
'''Yes''' in 12.00 FW. Maybe not working at all on PS5.
 
The bug was patched in PS4 FW 12.00 by adding some mutexes in bnet_netevent functions
----
 
=== FW <= 11.00 - Remote vulnerabilities in spp (yielding kernel ASLR defeat) (CVE-2006-4304 and no-CVE) ===
 
==== Credits ====
* 2006-08-23 Martin Husemann, Pavel Cahyna for discovering the first spp bug (CVE-2006-4304) on FreeBSD 4.11-6.1.
* 2023-09-22 TheFloW for discovering that PS4 and PS5 are vulnerable to CVE-2006-4304, discovering second spp bug, and chaining them together.
* 2024-01-27 anonymous for reporting publicly CVE-2006-4304 as working on PS4 and PS5. See [https://i0.wp.com/wololo.net/wagic/wp-content/uploads/2024/02/initial_claims.png?w=603&ssl=1] and [https://ibb.co/sVb39Zj].
* 2024-03 iMrDJAi for porting CVE-2006-4304 to PS4 and PS5.
* 2024-04-25 TheFloW for disclosing his HackerOne report including the second spp bug description.
* 2024-04-30 TheFloW for releasing his exploit code for PS4 9.00 and 11.00.
 
==== Analysis ====
* [https://www.freebsd.org/security/advisories/FreeBSD-SA-06:18.ppp.asc FreeBSD Security Advisory for CVE-2006-4304 (2006-08-23)]
* [https://hackerone.com/reports/2177925 HackerOne report about Remote vulnerabilities in spp by TheFloW (2023-09-22)]
* [https://romhack.io/wp-content/uploads/sites/3/2024/10/Andy-Nguyen-PlayStation-4-Remote-Kernel-Exploitation-RomHack-2024.pdf Slides of TheFloW's presentation at RomHack 2024 (2024-09-28)]
* [https://www.youtube.com/watch?v=LRdbnGkk7JA Video of TheFloW's presentation at RomHack 2024 (2024-09-28)]
 
==== Bug Description ====
A malicious PPPoE server can cause denial-of-service or remote code execution in kernel context on the PS4/PS5. It does not require any usermode code execution to be triggered. There are two vulnerabilities that can be chained together to cause remote kernel Denial of Service, kernel ASLR defeat or kernel code execution : Heap buffer overwrite and overread in sppp_lcp_RCR and sppp_ipcp_RCR (CVE-2006-4304) and Integer underflow in sppp_pap_input leading to heap-buffer overread (no-CVE).
 
The PS4/PS5 must be connected using an ethernet cable to a device able to trigger PPPoE requests and analyze the responses.
 
==== Exploit Implementation ====
* [https://github.com/iMrDJAi/FreeBSD9-CVE-2006-4304 CVE-2006-4304 PoC for FreeBSD9 by iMrDJAi (2024-04-07)]
* [https://gist.github.com/iMrDJAi/847a4f2eeff9669657ffcdf85ac7a901 CVE-2006-4304 PoC for PS4 and PS5 by iMrDJAi (2024-04-07)]
* [https://github.com/TheOfficialFloW/PPPwn spp exploit for PS4 9.00 and 11.00 by TheFloW (2024-04-30)]
 
==== Patched ====
'''Yes''' in 11.02 FW
----


=== FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867) ===
=== FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867) ===
Line 1,167: Line 909:


==== Patched ====
==== Patched ====
'''Yes''' in PS4 9.03 FW and PS5 4.50 FW
'''Yes''' in PS4 9.03 FW and PS5 4.50 FW.
----
----


Line 1,243: Line 985:


==== Patched ====
==== Patched ====
'''Yes''' in PS4 7.50 FW and in PS5 5.00 or 5.02 FW. Not working in PS5 FWs <= 2.70.
'''Yes''' in PS4 7.50 FW and in PS5 5.00 or 5.02 FW. Not working in PS5 FWs <= 2.50.
----
----


Line 1,319: Line 1,061:


==== Analysis ====
==== Analysis ====
* [https://fail0verflow.com/blog/2017/ps4-namedobj-exploit/ fail0verflow's writeup on the PS4 1.01-4.05 namedobj kernel exploit] (2017-10-19)
* [https://fail0verflow.com/blog/2017/ps4-namedobj-exploit/ fail0verflow's writeup on the 1.01-4.05 namedobj kernel exploit] (2017-10-19)
* [https://github.com/Cryptogenic/Exploit-Writeups/blob/master/PS4/NamedObj%20Kernel%20Exploit%20Overview.md Specter's first writeup] (2017-10-20)
* [https://github.com/Cryptogenic/Exploit-Writeups/blob/master/PS4/NamedObj%20Kernel%20Exploit%20Overview.md Specter's first writeup] (2017-10-20)
* [https://github.com/Cryptogenic/Exploit-Writeups/blob/master/PS4/%22NamedObj%22%204.05%20Kernel%20Exploit%20Writeup.md Specter's writeup on his PS4 4.05 implementation] (2017-12-28)
* [https://github.com/Cryptogenic/Exploit-Writeups/blob/master/PS4/%22NamedObj%22%204.05%20Kernel%20Exploit%20Writeup.md Specter's writeup on his 4.05 implementation] (2017-12-28)
* [https://github.com/RPCSX/rpcsx/blob/0bbab3eae53d01afbcdb16e97043b58e26fb54bd/orbis-kernel/src/sys/sys_sce.cpp#L469 Reimplementation of the sys_namedobj_create function in the RPCSX emulator]
* [https://wololo.net/2023/09/04/ps4-ps5-reverse-engineering-101-the-basics-of-ps4-exploits/ Short analysis by wololo (2023-09-04)]


==== Bug Description ====
==== Bug Description ====
Line 1,329: Line 1,069:


==== Exploit Implementation ====
==== Exploit Implementation ====
* [https://github.com/Cryptogenic/PS4-4.05-Kernel-Exploit PS4 4.05 WebKit + Kernel Exploit]
[https://github.com/Cryptogenic/PS4-4.05-Kernel-Exploit PS4 4.05 WebKit + Kernel Exploit]


==== Patched ====
==== Patched ====
Line 1,336: Line 1,076:
==== Tested ====
==== Tested ====
Works on FWs 4.00-4.05. On <= 3.70 FW we have not found a way to leak the target object, but it might be doable as Fail0verflow did it on 1.01.
Works on FWs 4.00-4.05. On <= 3.70 FW we have not found a way to leak the target object, but it might be doable as Fail0verflow did it on 1.01.
----
=== FW <= ?4.05? - amd64_set_ldt Heap Overflow (CVE-2016-1885) ===
==== Credits ====
* 2016-10-25 This vulnerability was discovered and researched by Francisco Falcon from Core Exploit Writers Team
* 2016-10-25 Revised patch to address a problem pointed out by ahaha from Chaitin Tech.
==== Analysis ====
* https://www.freebsd.org/security/advisories/FreeBSD-SA-16:15.sysarch.asc
* https://www.coresecurity.com/core-labs/advisories/freebsd-kernel-amd64setldt-heap-overflow
* https://web.archive.org/web/20161028222346/https://www.securityfocus.com/archive/1/archive/1/537812/100/0/threaded
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1885
* https://www.mail-archive.com/[email protected]/msg132464.html
* https://svnweb.freebsd.org/base?view=revision&revision=296956
* https://wololo.net/2016/10/26/details-surface-ps4-4-01-jailbreak-potentially-enough-public-release-soon
==== Bug Description ====
The IA-32 architecture allows programs to define segments, which provides based and size-limited view into the program address space. The memory-resident processor structure, called Local Descriptor Table, usually abbreviated LDT, contains definitions of the segments. Since incorrect or malicious segments would breach system integrity, operating
systems do not provide processes direct access to the LDT, instead they provide system calls which allow controlled installation and removal of segments.
A special combination of sysarch(2) arguments, specify a request to uninstall a set of descriptors from the LDT. The start descriptor is cleared and the number of descriptors are provided. Due to lack of sufficient bounds checking during argument validity verification, unbound zero'ing of the process LDT and adjacent memory can be initiated from usermode.
sysarch is syscall #165 on FreeBSD 9.1 and on PS4. Sony removed set_ldt between System Software version 1.76 and 4.05, according to Red-EyeX32.
==== Exploit Implementation ====
==== Patched ====
'''Yes''' in some FW <= 4.05 and >= 2.00 as set_ldt was removed. The PS4 is maybe not vulnerable because of a possible lack of 32bit implementation for syscalls.
==== Tested ====
Not yet.
----
=== <= 3.15 - .symtab kernel table of symbols kept on low FWs ===
==== Credits ====
* CelesteBlue for backporting kernel exploits to dump PS4 3.50 kernel (2019-05-09) and 3.15 (2019-05-25)
* zecoxao and SocraticBliss for analysing kernel dumps
==== Bug description ====
After Sony removed .strtab since FW 1.03 and .dynstr/.dynsym since FW 2.50 from PS4 kernel binary, they still kept the .symtab one.
==== Patched ====
'''Yes''' in 3.50 FW.
----
=== <= 2.50 - .dynstr/.dynsym kernel table of symbols kept on low FWs ===
==== Bug description ====
After Sony removed .strtab from PS4 kernel binary since FW 1.03, they still kept the .dynstr/.dynsym one.
==== Patched ====
'''Yes''' in 2.50 FW.
----
----


Line 1,444: Line 1,130:
==== Patched ====
==== Patched ====
'''Yes''' in 2.00 FW
'''Yes''' in 2.00 FW
----


=== FW ??? - setlogin Information Leak (CVE-2014-8476) ===
=== FW ??? - setlogin Information Leak (CVE-2014-8476) ===
Line 1,472: Line 1,157:


==== Patched ====
==== Patched ====
Maybe.
?
----
 
=== <= 1.01 - .strtab/.symtab kernel table of symbols kept on very low FWs ===
 
==== Bug description ====
 
* Sony used to have two tables of symbols on very low versions: .strtab/.symtab and .dynstr/.dynsym (.strtab/.symtab had all symbols, .dynstr/.dynsym had ~75% of them).
 
==== Patched ====
'''Yes''' in 1.03 FW. Seen in 1.01 PS4 kernel.


== Kernel securities ==
== Kernel securities ==
Line 1,508: Line 1,183:
* [https://github.com/sleirsgoevy/ps4jb/blob/master/src/oldkex.c#L451 cli/sti SMAP bypass in 6.72 PS4 kernel exploit]
* [https://github.com/sleirsgoevy/ps4jb/blob/master/src/oldkex.c#L451 cli/sti SMAP bypass in 6.72 PS4 kernel exploit]


==== PS5 SMAP bypass method: CVE-2021-29628 ====
==== SMAP bypass method: CVE-2021-29628 ====


A SMAP bypass has been found by m00nbsd while working on FreeBSD 12. It is named CVE-2021-29628 and affects FreeBSD 12.2 and later (til it was patched). It does not work on PS4 because PS4 kernel is based on FreeBSD 9 which did not contain the vulnerability and because PS4 SMAP does not come from FreeBSD but is custom from Sony. It used to work on PS5 before it was disclosed and patched. See [https://www.psdevwiki.com/ps5/Vulnerabilities#SMAP_bypass_%28CVE-2021-29628%29 CVE-2021-29628 on PS5 Dev Wiki].
A SMAP bypass has been found by m00nbsd while working on FreeBSD 12. It is named CVE-2021-29628 and affects FreeBSD 12.2 and later (til it was patched). It does not work on PS4 because PS4 kernel is based on FreeBSD 9 which did not contain the vulnerability and because PS4 SMAP does not come from FreeBSD but is custom from Sony. It used to work on PS5 before it was disclosed and patched on PS5 FW 2.30 or later according to dates.
 
* [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29628 CVE-2021-29628 (FreeBSD SMAP bypass) by m00nbsd]
* [https://hackerone.com/reports/1048322 CVE-2021-29628 (PS5 SMAP bypass) by m00nbsd]


=== CR0.WP protection ===
=== CR0.WP protection ===


At least since PS4 System Software version 6.51, Sony instrumented all instructions that write to the CR0 register with checks for attempts to clear CR0.WP (Write Protect), which is necessary for patching the kernel. This is what it looks like in 6.51 kernel:
At least since firmware 6.51 Sony instrumented all instructions that write to the CR0 register with checks for attempts to clear CR0.WP (Write Protect), which is necessary for patching the kernel. This is what it looks like in 6.51 kernel:


   a1b79:      0f 22 c0                mov    cr0,rax
   a1b79:      0f 22 c0                mov    cr0,rax
Line 1,525: Line 1,203:


Bypasses (in chronological order):
Bypasses (in chronological order):
* Execute an unintended "move to cr0" instruction in the middle of another instruction (e.g. instruction "call $+0x220f1c" (e8 17 0f 22 00) contains an unintended "mov cr0, rax" (0f 22 00))
* Use kernel write to give your process JIT permissions, allocate JIT memory, and put entirely custom code there (avoids the problem altogether, as it is specific to ROP). This seems impossible on PS5 with a classic kernel exploit because of XOM.
* Since the IDT (Interrupt Descriptor Table) is writable on FreeBSD, PS4 and PS5, it is possible to overwrite an exception handler without clearing CR0.WP first. One can overwrite the handler of #UD with a gadget of their choice (a stack pivot, or an "add rsp, ... ; ret" instruction, or whatever), then the UD2 instruction in the mitigation code will happily jump to it instead of the real handler, with CR0.WP cleared. To be precise, one must set up IDT handlers and point the IST (Interrupt Stack) to a ROP chain. It is required to poison the upper 16 bits of a pointer to make it non-canonical. Finally, write a custom page fault handler to run any kernel code you want. This technique proposed by sleirsgoevy since PS4 System Software version 6.51 was later adapted to PS5. However, this method slows down system performance compared to native execution because alone it can just run kernel ROP chains and it requires knowledge of gadgets positions. So on PS4, it is better to only use the IDT trick initially in a kernel exploit to patch kernel and allow non-ROP code execution for example by allowing JIT. On PS5, it is required to bypass XOM so an hypervisor exploit is required.
== Secure Modules ==
=== <= ?7.55? - Missing HMAC key length check in Secure Kernel leading to Partial SAMU KeyRings bruteforce ===
==== Credits ====
* 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 ====
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.
Finally, one can retrieve its per-console VTRM keys (which are notably used for per-account securities like for act.dat and [[RIF]]).
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].
==== Analysis ====
* https://yifan.lu/2017/02/19/psvimgtools-decrypt-vita-backups/
* https://twitter.com/qlutoo/status/1027691272369262594
* 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)]
==== 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/tree/samu_key_dump Implementation for PS4 5.05 by jogolden (2023-03-18)]
* [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 (2021-12-18)]
==== Patched ====
'''Yes''' since a PS4 FW between 7.55 (unpatched) and 9.00 (patched).
----
=== <= 4.07 - Crashdumps encryption using symmetrical key and same key across software revisions ===
==== Credits ====
* Discovered by ps4_enthusiast of fail0verflow (2017-12-27).
==== Bug description ====
The PS4 crashdumps encryption keys never changed between 1.01 and 3.15 FWs. Then between 3.50 and 4.07 FWs, Sony developers changed the keys many times but still used symmetrical key.
==== Analysis ====
* [https://fail0verflow.com/blog/2017/ps4-crashdump-dump/#crashdump-decryptor Writeup by ps4_enthusiast of fail0verflow (2017-12-27)]
==== Patched ====
'''Yes''' on PS4 FW 4.50 by using asymmetrical key. Tested between 1.01 and 4.07 PS4 FWs.
----


=== <= 3.70 - Reused keys lead to decryption of any PS4 1.00- 3.70 usermode SELF ===
* Use an "unintended" mov to cr0 in the middle of another instruction (e.g. instruction "call $+0x220f1c" (e8 17 0f 22 00) contains an unintended "mov cr0, rax" (0f 22 00))
 
* Use kernel write to give your process JIT permissions, allocate JIT memory, and put entirely custom code there (avoids the problem altogether, as it is specific to ROP)
==== Bug description ====
* Since the IDT is writable on FreeBSD and PS4, it is possible to overwrite an exception handler without clearing CR0.WP first. One can overwrite the handler of #UD with a gadget of their choice (a stack pivot, or a "add rsp, ... ; ret", or whatever else), and the UD2 instruction in the mitigation code will happily jump to it instead of the real handler, with CR0.WP cleared.
 
Sony reused encryption keys from System Software version 1.00 to 3.70 for PS4 usermode modules. As a result, any PS4 usermode module from those FWs can be decrypted on a PS4 running FW between 1.00 and 3.70.
 
==== Patched ====
 
'''Yes''' in 4.00 FW with the introduction of new keyset.
----
 
=== <= 2.50 - IDPS leak in sceSblAuthMgrDriveData on low retail FWs ===
 
==== Credits ====
 
* Discovered by flatz (2018-08-27).
 
==== Bug analysis ====
 
By calling the sceSblAuthMgrDriveData kernel function on a PS4, which is a wrapper to the Authentication Secure Module associated fonction, it is possible to dump its IDPS ([[Console ID]]). It is possible because some PlayStation 4 operating system developer from Sony forgot to encrypt sceSblAuthMgrDriveData output by the Authentication Secure Module and that is how it was patched later. The PS4 IDPS is stored encrypted in an EID block in the [[Serial Flash]].
 
To dump the PS4's IDPS, execute sceSblAuthMgrDriveData(0, in_buf, 0x160, out_buf, 0xA4, 1). Pass 0x160 bytes at 0x90C00 from sflash0s1.crypt into `in_buf` and dump `out_buf`.
 
==== Analysis ====
 
==== Implementation ====
 
==== Patched ====
 
'''Yes''' in PS4 3.00 retail FW. Works on any PS4 TestKit/DevKit FW.
----
 
=== <= ?1.62? - Missing version checks allow decryption of any GEN3 PUP ===
 
==== Credits ====
 
* Discovered by flatz (2016).
 
==== Bug description ====
 
A bug in the Secure Module that handle PUP decryption allows any PS4 GEN3 on FW 1.62 or below to decrypt any GEN3 PUP (retail, TestKit, DevKit, Beta) with a version above 1.00 (post-prototype).https://github.com/SocraticBliss/ps4-pup_decrypt
 
The Secure Module mailbox code does not reset state after [[SMI]] checks failure, so to decrypt an arbitrary PUP, you need to ignore the mailbox error after executing the PupDecryptHeader command (1).
 
==== Implementation ====
 
Any PS4 PUP decryptor kernel payload that ignore the mailbox error could be used. See [[PUP#Decrypter_%28first_step%29]] for implementations.
 
==== Patched ====
 
'''Yes''' around PS4 FW 1.70.
 
== Secure Kernel ==
 
=== <=?3.70? - Kernel ASLR collision leads to decrypted kernel partial leak - Matroska vulnerability ===
 
==== Credits ====
* anonymous for sharing decrypted PS4 6.00b1 kernel file (2019-03-20)
* shykelit for dumping 3.55 Jig PS4 kernel (2019-04-17)
* zecoxao for discovering Matroska kernels and giving them that name (2019-04-18)
* z80 for dumping 3.70 PS4 DevKit kernel (2019-04-18)
* AlexAltea for reverse engineering kernel, ubios and vbios
* Many people for sharing dumps of their PS4 kernels
* CelesteBlue for backporting kernel exploits to dump PS4 4.74 kernel (2018-11-18), 3.50 (2019-05-09), 3.70 (2019-05-15) and 3.15 (2019-05-25)
 
==== Bug description ====
The kernel memory contains the kernel fSELF but with decrypted data, which in turn can be decompressed to grab ubios, vbios, kernel boot code and partial kernel.
 
By dumping PS4 kernel memory with a kernel exploit, in order to dump the x86 kernel, we sometimes find a strange fSELF. This fSELF is only partial: 1.5MB, but should be 17MB if it was the x86 kernel. Luckily it is only compressed, not encrypted. When uncompressing it using offzip, we can see only 1 segment. That is because the other segments have been cutted and the segment is incomplete. But we can see that it is the decrypted x86 kernel, as confirmed by diffing with anonymously shared decrypted full x86 kernel. In the decrypted x86 kernel, you can see a second ELF header. It is once again only compressed and not encrypted, and this is what zecoxao named the "Matroska kernel".
 
Sadly, this vulnerability is random, as it relies on kernel ASLR which is itself random. So depending on the System Software version, as modules have different sizes, kernel ASLR has more (100% on 3.15, 3.50 and 3.70) or less (1% on ?4.74?) chances to leak the Matroska kernel. It is unknown how we could improve this success rate. Maybe by instead of rebooting, causing a kernel panic or rebooting to recovery, entering rest mode then disconnecting power supply. A way to accelerate the process would be to scan kernel memory and check magics to see if there is a Matroska kernel. If there is, dump it, else reboot and cross fingers.
 
Note: vbios seems to be the same from 3.50 to 6.00b1 at least.
 
==== Analysis ====
Since PS4 3.50 FW, ASLR (Address Space Layout Randomization) has been enabled in PS4 kernel.
 
During PS4 boot, the following operations are executed:
* the encrypted x86 kernel is loaded from [[Serial Flash]]
* the secure kernel decrypt the x86 kernel SELF, without uncompressing it to some fixed address: at 0xFFFFFFFF84000000 in the case of 3.xx and 5.xx firmwares or 0xFFFFFFFFC4000000 in the case of 4.xx.
* the secure kernel randomly chooses a base address for Kernel ASLR, starting from 0xFFFFFFFF80000000.
* the secure kernel uncompresses the x86 kernel to the address determined by Kernel ASLR.
 
On some PS4 boots, Kernel ASLR base address can be very near of Matroska kernel address and the lack of memory separation and wipe renders the dump of Matroska kernel possible with only kernel memory read access.
 
==== Patched ====
'''Yes''' partially in 4.00 FW by increasing the kernel ASLR base address but it might have reappeared in newer versions like since 5.00 or 4.74, but with lower success rate.
 
It was also not present on 1.76 and below, so probably appeared when Sony worked on adding ASLR in PS4 Kernel. Also note that Matroska kernel is present on 3.15 even though there is no Kernel ASLR in this version.
 
== Hardware ==
 
=== PCIe man-in-the-middle attack ===
 
* First done on PS4 FW 1.01 by failoverflow on PS4 launch!
* Detailed at 33c3: [https://fail0verflow.com/media/33c3-slides/#/5 33c3 slides by Marcan]
* Permits kernel and usermode dumping
 
=== Syscon glitching ===
 
It is possible to glitch the [[Syscon]] debug interface to allow access and dump keys. It was originally done by an anonymous member of fail0verflow.
 
=== Aeolia and Belize (Southbridge) SCA/DPA ===
 
Side Channel Analysis (SCA) with Differential Power Analysis (DPA) on Aeolia and Belize (PS4 Southbridge revisions) has been shown to be able to recover key material. Since Sony never used private/public key pairs, it is possible to exploit this and gain complete control over the [[Southbridge]]. You can attack the main FreeBSD kernel from here.
 
Nearly same methods are working on recent PS4 Pro motherboard NVB-003 that has Belize [[Southbridge]] ([[CXD90046GG]]).
 
Contrarly to Aeolia, Belize has ROM readout protection and clears stack which makes it more secure.
 
Old notes:
 
This is a 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. 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).
 
Related:
* [https://fail0verflow.com/blog/2018/ps4-aeolia/ fail0verflow's writeup]
* [https://twitter.com/fail0verflow/status/1047690778527653889 fail0verflow's tweet]
* [https://www.youtube.com/watch?v=sMroXa-zYxk PlayStation 4 Rest Mode DEMO REcon Brussels 2018 by Volodymyr Pikhur]
* [https://recon.cx/2018/brussels/resources/slides/RECON-BRX-2018-Mess-with-the-best-die-like-the-rest_(mode).pdf Slides of REcon Brussels 2018 by Volodymyr Pikhur]
* [https://www.psxhax.com/threads/ps4-southbridge-reverse-engineered-code-examination-by-jogolden.6736/ jogolden's writeup]
 
=== Arbitrary code execution in AMD SMU by incomplete hashing and bounds checking ===
 
==== Credits ====
* Rudolf Marek discovered, disclosed to AMD then publicly through the following timeline:
** Christmas 2013 - SMU firmware was analyzed from public AMD documentation
** April 2014 - Bug was found in the SMU firmware
** 2014-04-30 - Request to AMD sent
** 2014-05-15 - Reply by AMD
** 2014-05-16 - Encrypted communication, sending details
** 2014-07-09 - AMD acknowledges the problem
** In the meanwhile - Occasional communication
** 2014-11-25 - AMD sends to Rudolf Marek a list of AMD AGESA versions which contain a fix
 
==== Bug description ====
A security vulnerability, discovered by Rudolf Marek in April 2014, in the recent AMD processors (Trinity and Richland, of FM2 socket) allows arbitrary code execution on the AMD System Management Unit (SMU).
 
It consists in two bugs in the SMU of AMD Trinity and Richland CPUs:
* The AMD SMU firmware is not padded so some part (256 bytes) of the runtime firmware is not correctly covered by protection cover (0x55 0xaa ...).
* The AMD SMU request function incorrectly checks bounds.
Similar, but not same problem affected AMD Kabini and Kaveri CPUs. It also likely affects PS4 as its [[APU]] is AMD Kabini/Jaguar.
 
Thanks to this vulnerability, the AMD SMU firmware can be dumped. From the dump, the [[Keys#AMD_SMU_Keys HMAC-SHA1 key]] was obtained.
 
Thanks to the knowledge of this key, the AMD SMU firmware could possibly be replaced by a custom one.
 
==== Analysis ====
* [https://fahrplan.events.ccc.de/congress/2014/Fahrplan/system/attachments/2503/original/ccc-final.pdf Slides about exploitation AMD SMU firmware exploitation at 31C3 by Rudolf Marek (2014-12-27)]
* [https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek Video of Rudolf Marek explaining AMD SMU firmware exploitation at 31C3 (2014-12-27)] or [https://www.youtube.com/watch?v=iYvhHey_dTk mirror]
 
==== Patched ====
Maybe after 2014-11-25, SMU vulnerability found by Rudolf Marek could have been patched on PS4 as AMD released patches: the fixed SMU firmware is part of updated AMD AGESA.
 
=== Untested - Arbitrary code execution in AMD SMU by custom firmware ===
 
==== Credits ====
* Rudolf Marek for his exploit and documentation (2014)
* zecoxao for public disclose (2023-05-17)
 
==== Bug description ====
It turns out that the "debug key" used to hash "debug" firmwares from AMD SMU effectively works on all retail (CEX) versions of the PS4 AMD SMU firmware as well.
 
According to zecoxao, as SMU is very privileged in PS4 (but not so privileged in PS5), one could probably dump his own PS4 keys/fuses with AMD SMU code execution. This could possibly lead to decryption of latest PS4 games, SEN access on PS4 running out-of-date System Software, conversion of any PS4 between CEX and DEX, as well as decrypting the PS4 Kernel and derived binaries.
 
==== Analysis ====
* [https://wololo.net/2023/05/18/ps4-reverse-engineering-progress-on-smu-system-management-unit-could-help-with-hacks/ Article by wololo (2023-05-18)]
 
==== Patched ====
Maybe on recent PS4 firmwares with a BIOS update that would require a different and possibly more secure digest or signature.




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)