Editing Vulnerabilities
Jump to navigation
Jump to search
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: | ||
== | == To sort exploits == | ||
=== Decryption of any GEN3 PUP === | |||
* Discovered by flatz. | |||
* 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). | |||
* SM code doesn't reset state after SMI checks failure, so to decrypt arbitrary PUP, you need to ignore mailbox error after PupDecryptHeader cmd (1). | |||
* Fixed around 1.70 | |||
=== Decryption of any usermode SELF from FW 1.00 to 3.70 === | |||
* 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. | |||
* Fixed in 4.00 with the introduction of new keyset. | |||
=== .strtab/.symtab kernel table of symbols kept on very low FWs === | |||
* 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). | |||
* Seen in 1.01 kernel. Patched in 1.03. | |||
=== .dynstr/.dynsym kernel table of symbols kept on low FWs === | |||
* After Sony removed .strtab/.symtab, they still kept the .dynstr/.dynsym one. | |||
* Patched in 2.50 | |||
=== IDPS leak in sceSblAuthMgrDriveData on low retail FWs === | |||
* Discovered by flatz. | |||
* 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`. | |||
* It is possible because someone from sony forgot to encrypt output and that is how it was patched later. | |||
* Patched in 3.00 retail. Works on any TestKit/DevKit FW. | |||
=== Partial SAMU KeyRings bruteforce by missing HMAC length check in secure kernel === | |||
* Discovered by flatz. | |||
* 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. | |||
* 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... | |||
Related: | |||
* https://twitter.com/qlutoo/status/1027691272369262594 | |||
* https://yifan.lu/2017/02/19/psvimgtools-decrypt-vita-backups/ | |||
* https://www.lolhax.org/2019/01/02/extracting-keys-f00d-crumbs-raccoon-exploit/ | |||
* [https://gist.github.com/flatz/22215327864d7512e52268f9c9c51cd8 Exploit PoC for PS4 FW 7.55] | |||
* Patched since a FW between 7.55 (unpatched) and 9.00 (patched). | |||
=== Crashdumps encryption using symmetrical key and same key across FW === | |||
* [https://fail0verflow.com/blog/2017/ps4-crashdump-dump/#crashdump-decryptor see FoF article] | |||
* 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. | |||
* Patched on FW 4.50 by using asymmetrical key. Tested between 1.01 and 4.07 FWs. | |||
== Hardware Exploits == | |||
=== PCIe man-in-the-middle attack === | |||
* 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 | |||
=== 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] | ||
== Usermode Exploits (Game Savedata) == | |||
=== PS2 games savedata exploits === | === PS2 games savedata exploits === | ||
==== GTA III ==== | |||
* [https://github.com/halpz/re3/blob/9a7fa478578beaba947ea867c15a25e411d641d8/src/save/MemoryCard.cpp#L358 vulnerability] | |||
The game does a copy from the memory card into a fixed-size buffer with size supplied by the savedata. | |||
==== Dark Cloud ==== | |||
* [https://www.youtube.com/results?search_query=%22dark+cloud%22+item+glitch+menu+before%3A2008-01-01 video of bug triggering] | |||
* | |||
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. | |||
=== | ==== Okage Shadow King ==== | ||
===== Credits ===== | |||
* CTurt for discovering these vulnerabilities in September 2021. | |||
* 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 | |||
* McCaulay for sharing publicly his implementation in February 2023. | |||
* https:// | ===== Analysis ===== | ||
* https:// | * [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)] | |||
===== 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. | |||
===== Exploit Implementation ===== | |||
* | * [https://github.com/McCaulay/okrager Okrager by McCaulay (2023-02-04)] | ||
===== Patched ===== | |||
'''No'''. Unpatchable in theory. | |||
* | |||
=== PS4/PS5 PS2emu sandbox escape (mast1c0re) === | === PS4/PS5 PS2emu sandbox escape (mast1c0re) === | ||
Advantages of the PS4/PS5 PS2emu sandbox escape exploit over most WebKit exploits: | 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 | * 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. | ||
* 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions | * 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 | * Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update | ||
Line 193: | Line 160: | ||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
* [https://github.com/McCaulay/mast1c0re | * [https://github.com/McCaulay/mast1c0re (2023-02-18)] | ||
==== Patched ==== | ==== Patched ==== | ||
'''No''' as of PS4 FW 11. | '''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) == | == Usermode Exploits (BD-J) == | ||
Line 228: | Line 173: | ||
* JIT enabled allowing to write a kernel exploit in C versus writing in assembly and JavaScript since around FW 2.00 | * 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 === | === FW <=10.71 - BD-JB2 - Path traversal sandbox escape by TheFloW === | ||
==== Credits ==== | ==== Credits ==== | ||
Line 246: | Line 191: | ||
'''No''' as of PS4 FW 10.71 (maybe patched on PS4 FW 11.00). '''Yes''' on PS5 FW 8.00. | '''No''' as of PS4 FW 10.71 (maybe patched on PS4 FW 11.00). '''Yes''' on PS5 FW 8.00. | ||
=== FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW === | === FW <=9.00 - BD-JB - Five vulnerabilities chained by TheFloW === | ||
==== Credits ==== | ==== Credits ==== | ||
Line 285: | Line 230: | ||
== Usermode Exploits (WebKit) == | == Usermode Exploits (WebKit) == | ||
=== FW 6.00-9.60 - FrameLoader::loadInSameDocument UaF (CVE-2022-22620) leading to arbitrary RW === | |||
=== FW 6.00-9.60 - FrameLoader::loadInSameDocument | |||
==== Credits ==== | ==== Credits ==== | ||
* 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) | ||
* | * Anonymous for making an OOM PoC for webkit-gtk, PS4 and PS5 (2023-10-03) then making an arbitrary RW PoC for webkit-gtk, PS4 6.50-9.60 and PS5 1.00-5.50 (2023-10-24) | ||
* CelesteBlue for testing and porting | * CelesteBlue for testing and porting anonymous' arbitrary RW PoC to PS4 6.50-9.60 and PS5 1.00-5.50 (2023-11-04) | ||
==== Analysis ==== | ==== Analysis ==== | ||
Line 493: | Line 246: | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
The History API allows access to (and modification of) a stack of the pages visited in the current frame, and these page states are stored as a | The History API allows access to (and modification of) a stack of the pages visited in the current frame, and these page states are stored as a SerializedScriptValue. The History API exposes a getter for state, and a method replaceState which allows overwriting the "most recent" history entry. | ||
The bug is that | The bug is that FrameLoader::loadInSameDocument takes the state as an argument (stateObject), but does not increase its reference count. Only a HistoryItem object holds a reference to the stateObject. loadInSameDocument can trigger a callback into user JavaScript through the onblur event. The user's callback can call replaceState to replace the HistoryItem's state with a new object, therefore dropping the only reference to the stateObject. When the callback returns, loadInSameDocument will still use this free'd object in its call to statePopped, leading to the use-after-free. | ||
When | When loadInSameDocument is called it changes the focus to the element its scrolling to. If we set the focus on a different element prior to loadInSameDocument running, the blur event will be fired on that element. Then we can free the stateObject by calling replaceState in the onblur event handler. | ||
The bug is triggered by <code>history.back()</code> with the target state whose URL contains a hash | The bug is related to the web browser History API and is triggered by <code>history.back()</code> with the target state whose URL contains a hash: | ||
<source lang="js"> | <source lang="js"> | ||
history.pushState("state1", "", location + "#foo"); // URL with a hash | |||
// ... | |||
history.back(); // triggers loadInSameDocument() | |||
</source> | |||
The user may then trigger a double free and escalate it into an arbitrary read primitive. The exploit proceeds similarly to the buildBubbleTree() UaF exploit except the arbitrary decrement primitive is achieved from manipulating ~SerializedScriptValue(). | |||
A way to know if the system is vulnerable is the appearance of the input HTML element in the PoC page. If the HTML input field stays focused (blue outline) after the second timeout, then the vulnerability is not present. Note that Maddie Stone's PoC will never trigger any sort of crash on release builds as it was meant for builds with memory sanitation that can detect UaFs. | |||
By default, arguments to functions should be reference-counted. Raw pointers should only be used in rare exceptions. | |||
The bug was killed in 2013 and re-introduced in 2016. It seems that this likely occured due to the large issues affecting most software dev teams: legacy code, short reviewer turn-around expectations, refactoring and security efforts are generally under-appreciated and under-rewarded, and lack of memory safety mitigations. Steps towards any of these would likely make a difference. | |||
The | |||
The | The two commits that reverted the 2013 fix were very, very large commits: 40 and 94 files changed. While some large commits may include exclusively no-ops, these commits included many changes affecting lifetime semantics. This seems like it would make it very difficult for any developer or reviewer to be able to truly audit and understand the security impacts of all the changes being made. | ||
This bug was actually reported and initially fixed in 2013. In 2016 the fix was regressed during (it seems) refactoring. It seems reasonable that the vulnerability could have been found through watching the commits and seeing the initial fix from 2013 reverted in 2016, code auditing, or fuzzing. Fuzzing seems slightly less likely due to needing to support "navigation" which many fuzzers explicitly try to exclude. | |||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
* 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 | * [https://discord.com OOM PoC for PS4 and PS5 by anonymous on ps4-dev discord (to mirror)] | ||
* [https://discord.com Arbitrary RW PoC | * [https://discord.com Arbitrary RW PoC for PS4 6.50-9.60 and PS5 1.00-5.50 by anonymous on ps4-dev discord (to mirror)] | ||
==== Patched ==== | ==== Patched ==== | ||
Line 545: | Line 281: | ||
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 working on PS4 FWs 6.50-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. PS4 FWs 6.00-6.20 pass the OOM PoC but "fail spray" in the arbitrary RW PoC. | |||
Tested working on PS4 FWs 6. | |||
=== 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 570: | Line 304: | ||
* [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 | * [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 576: | Line 310: | ||
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 | 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 588: | Line 322: | ||
==== 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. | * [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. | '''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. | 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 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. | |||
=== 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 626: | Line 358: | ||
==== 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 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 673: | Line 401: | ||
==== 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. | ||
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 699: | Line 424: | ||
==== 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". | ||
It does not work on <= 4.07 FW PS4 according to tests as the exploit fails at step "Triggering memory corruption". | |||
---- | ---- | ||
Line 842: | Line 564: | ||
==== Tested ==== | ==== Tested ==== | ||
Works on 3.15-4.07. Not working on <= 3.11 | Works on 3.15-4.07. Not working on <=3.11. | ||
---- | ---- | ||
Line 900: | Line 575: | ||
==== Analysis ==== | ==== Analysis ==== | ||
* [https://blog.xyz.is/2016/webkit-360.html PSVita 3.60 | * [https://blog.xyz.is/2016/webkit-360.html PSVita 3.60 HENKaku WebKit exploit writeup] | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
Line 918: | Line 593: | ||
=== FW <= 3.50 - WebCore::TimerBase::heapPopMin() Heap UaF leading to crash === | === FW <= 3.50 - WebCore::TimerBase::heapPopMin() Heap UaF leading to crash === | ||
==== Analysis ==== | ==== Analysis ==== | ||
* [https://github.com/WebKit/WebKit-http/commit/98845d940e30529098eea7e496af02e14301c704 WebKit fix commit ( | * [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 930: | Line 602: | ||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
* [http://psxhax.com/threads/ps4-3-50-webkit-exploit-from-playstation-4-dev-qwertyoruiop.450/ Article about qwertyoruiop's tests ( | * [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 ( | * [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 ( | * [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 | * [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 ( | * [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 942: | Line 614: | ||
==== 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. | ||
---- | ---- | ||
Line 1,043: | Line 689: | ||
* 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 ( | * nas and Proxima for the first PS4 POC on 1.76 PS4 (Oct. 23, 2014) | ||
* sony for patching the exploit in FW 2.00 ( | * 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 1,068: | Line 714: | ||
==== Tested ==== | ==== Tested ==== | ||
* Working on | * Working on 1.00-1.76 FW, AppleWebKit/531.3-536.26 | ||
* Might work on | * Might work on FW 0.930.020. | ||
== Usermode securities == | == Usermode securities == | ||
Line 1,084: | Line 726: | ||
=== Module imports table cleaned before execution === | === Module imports table cleaned before execution === | ||
* Between 1.76 and 4.05, Sony did that to prevent | * 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 1,097: | Line 739: | ||
=== 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 1,108: | Line 748: | ||
=== Syscalls removed === | === Syscalls removed === | ||
=== Syscall 0 disabled i.e Error Kernel: The application directly issues a syscall instruction (24) === | === Syscall 0 disabled i.e Error Kernel: The application directly issues a syscall instruction (24) === | ||
Line 1,122: | Line 760: | ||
=== 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. | |||
* | |||
=== 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 | * Around 6.50-6.70, device access got blocked or removed. Now you can no longer access devices from webbrowser | ||
== Kernel Exploits == | == Kernel Exploits == | ||
=== FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867) === | === FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867) === | ||
Line 1,308: | Line 885: | ||
==== 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,460: | Line 1,037: | ||
==== Analysis ==== | ==== Analysis ==== | ||
* [https://fail0verflow.com/blog/2017/ps4-namedobj-exploit/ fail0verflow's writeup on the | * [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 | * [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) | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
Line 1,470: | Line 1,045: | ||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
[https://github.com/Cryptogenic/PS4-4.05-Kernel-Exploit PS4 4.05 WebKit + Kernel Exploit] | |||
==== Patched ==== | ==== Patched ==== | ||
Line 1,476: | Line 1,051: | ||
==== 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. | ||
---- | ---- | ||
Line 1,585: | Line 1,106: | ||
==== 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,613: | Line 1,133: | ||
==== Patched ==== | ==== Patched ==== | ||
? | |||
== Kernel securities == | == Kernel securities == | ||
Line 1,649: | Line 1,159: | ||
* [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] | ||
==== | ==== 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. | 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 | 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,666: | Line 1,179: | ||
Bypasses (in chronological order): | Bypasses (in chronological order): | ||
* | * 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) | |||
* 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. | |||
* | |||
* the | |||