Editing Vulnerabilities

== 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 ===

==== 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.

===== Analysis =====
* [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) ===

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.
* 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 ====
* 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 ====
* [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 ====
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 ====
* [https://github.com/McCaulay/mast1c0re (2023-02-18)]

==== Patched ====
'''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) ==

Advantages of most BD-J exploits 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 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 ===

==== Credits ====
* 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 ====
* [https://twitter.com/theflow0/status/1701154155744645349 Removed tweet of BD-JB2 logs on a 7.61 PS5 by TheFloW (2023-09-11)]

==== Bug Description ====
Basing on BD-JB1 exploit files, in /bdmv/bdjo.xml changing bdjo/applicationManagementTable/baseDirectory to a path of the form `file:///app0/cdc/lib/../../../disc/BDMV/JAR/00000.jar` allows loading a JAR Java executable file.

==== Exploit Implementation ====
* [https://twitter.com/theflow0/status/1717088032031982066 PoC by TheFloW (2023-10-25)]

==== Patched ====
'''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 ===

==== Credits ====
* 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 ====
* [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 ====
TO ADD DESCRIPTION OF EACH ONE OF THE 5 BUGS:

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

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 ====
* [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 ====
'''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) ==

=== WebKit sources ===
[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 ===

==== Credits ====
* 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)
* 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 anonymous' PSFree to PS4 6.00-9.60 and PS5 1.00-5.50 (2023-11-04)

==== Analysis ====
* [https://github.com/WebKit/WebKit/commit/aa31b6b4d09b09acdf1cec11f2f7f35bd362dd0e WebKit bug-reintroducing commit by Darin Adler reviewed by Alex Christensen (2016-12-31)]
* [https://bugs.webkit.org/show_bug.cgi?id=235551 WebKit fix talk by Yusuke Suzuki reviewed by Mark Lam (2022-01-24)]
* [https://github.com/WebKit/WebKit/commit/486816dc355c19f1de1b8056f85d0bbf7084dd6e WebKit fix commit by Yusuke Suzuki reviewed by Mark Lam (2022-01-25)]
* [https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2022/CVE-2022-22620.html Short writeup by Maddie Stone (2022-06-14)]
* [https://googleprojectzero.blogspot.com/2022/06/an-autopsy-on-zombie-in-wild-0-day.html Detailed writeup by Maddie Stone (2022-06-14)]

==== 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 <code>SerializedScriptValue</code>. The History API exposes a getter for state, and a method <code>replaceState()</code> which allows overwriting the "most recent" history entry.

The bug is that <code>FrameLoader::loadInSameDocument()</code> takes the state as an argument (<code>stateObject</code>), but does not increase its reference count. Only a <code>HistoryItem</code> object holds a reference to the <code>stateObject</code>. <code>loadInSameDocument()</code> can trigger a callback into user JavaScript through the <code>onblur</code> event. The user's callback can call <code>replaceState()</code> to replace the <code>HistoryItem</code>'s state with a new object, therefore dropping the only reference to the <code>stateObject</code>. When the callback returns, <code>loadInSameDocument()</code> will still use this free'd object in its call to <code>statePopped()</code>, leading to the use-after-free.

When <code>loadInSameDocument()</code> is called it changes the focus to the element its scrolling to. If we set the focus on a different element prior to <code>loadInSameDocument()</code>'s execution, the blur event will be fired on that element. Then we can free the <code>stateObject</code> by calling <code>replaceState()</code> in the <code>onblur</code> event handler.

The bug is triggered by <code>history.back()</code> with the target state whose URL contains a hash. Here's a Proof-of-Concept that will crash:
<source lang="js">
input = document.body.appendChild(document.createElement('input'));

foo = document.body.appendChild(document.createElement('a'));
foo.id = 'foo';

function pop(event) {
    alert('you get a crash after you close this alert');
    event.state; // use the freed SerializedScriptValue
    alert('WebKit version not vulnerable');
}

addEventListener('popstate', pop);

history.pushState('state1', '', location + '#foo'); // URL with a hash
history.pushState('state2', '');

setTimeout(() => {
    input.focus();
    input.onblur = () => {
        history.replaceState('state3', '')
    };
    setTimeout(() => {
        history.back(); // trigger loadInSameDocument()
    }, 1000);
}, 1000);

</source>
The user may then trigger a double free and escalate it into an arbitrary read primitive via spraying <code>WTF::StringImpl</code>s like in the <code>buildBubbleTree()</code> UaF exploit. The read primitive is used to create the <code>addrof()</code> primitive and is used to save addresses of buffers that will be used to modify a <code>SerializedScriptValue</code>. After freeing the StringImpl (triple free), <code>SerializedScriptValue</code>s are sprayed via the <code>postMessage()</code> JavaScript function until one is allocated using the previously freed memory.

The method used to modify the fields of the <code>StringImpl</code> for arbitrary reads can be used can also be used to modify the <code>SerializedScriptValue</code>. Appropriate fields can modified to have deserialization create a <code>JSC::JSArrayBufferView</code> whose <code>m_vector</code> field will point to another <code>JSArrayBufferView</code>, which  will be called the worker. The user can modify the worker's fields for arbitrary read/write. Deserialization is done via <code>msg.data</code> where <code>msg</code> is the <code>MessageEvent</code> from <code>postMessage()</code>.

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.

==== Exploit Implementation ====
* 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://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 anonymous on ps4-dev discord (to mirror)]

==== Patched ====
'''Yes''' on PS4 FW 10.00 and PS5 FW 6.00.

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.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 ===

There are many FontFaceSet vulnerabilities. Explore [https://trac.webkit.org/search?q=mmaxfield%40apple.com+FontFaceSet&noquickjump=1&changeset=on].

==== Credits ====
* Myles C. Maxfield (litherum), Apple, for adding the vulnerability in WebKit (2016-02-22) then fixing and so disclosing the vulnerability (2021-08-26)
* Maddie Stone, Google Project Zero, for sharing a write-up describing this vulnerability (2021-10-13)
* PS Test discord server community for testing PoCs of many WebKit vulnerabilities on their PS4s (2021-10-13)
* sleirsgoevy for making the first exploit PoC for Safari (2021-10-24) and the first exploit PoC for PS4 FW 9.00-9.04 and PS5 FW 3.00-4.50 (2021-10-27)

==== Analysis ====
* [https://github.com/WebKit/WebKit/commit/d5dbfd02054e9f904b27224a598ca1bb8ded5f87 WebKit bug-introducing commit by Myles C. Maxfield - r256659 (2016-02-22)]
* [https://trac.webkit.org/changeset/281648/webkit WebKit fix commit by Myles C. Maxfield - r281648 (2021-08-26)]
* [https://github.com/WebKit/WebKit/commit/b22be72a013442ca9d1ff4bf3aa8aa436f78f142 WebKit commit adding FontFace tests (2021-09-01)]
* [https://bugs.webkit.org/show_bug.cgi?id=229848 WebKit Bugzilla - Bug 229848 - FontFaceSet.has() needs to react to style changes by Myles C. Maxfield (2021-09-02)]
* [https://github.com/web-platform-tests/wpt/pull/30322#issue-726455679 web-platform-tests - Add a test for FontFaceSet.has() #30322 (2021-09-03)]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1729089#c4 Mozilla Bugzilla - New wpt failures in /css/css-font-loading/fontfaceset-has.html (with TypeError `fonts.keys() is not iterable`, due to FontFaceSetIterator not behaving like an Iterable) (2021-09-03)]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1729997 Mozilla Bugzilla - FontFaceSet's iterators skip items when previous items are removed by Myles C. Maxfield (2021-09-09)]
* [https://bugs.webkit.org/show_bug.cgi?id=230119 WebKit Bugzilla - Bug 230119 - FontFaceSet's iterators skip items when previous items are removed by Myles C. Maxfield (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://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)]

==== Bug Description ====
Description in WebKit fix commit by Myles C. Maxfield:

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:

The vulnerability is a use-after-free due to an unchecked end() iterator. There was an assert statement: ASSERT(iterator != m_facesLookupTable.end());, but ASSERTs do not do anything in release builds. Therefore, even if iterator == m_facesLookupTable.end() in the release build, nothing would happen and iterator would still be used. In FontFaceSet a FontFace is not added to the faces lookup table in addToFacesLookupTable if the font has already been deemed to be invalid. However, removeFromFacesLookupTable would still attempt to remove the font, leading to the use-after-free. The patch changes the ASSERT to an if clause. The function will return if iterator == m_facesLookupTable.end(), since the item it wishes to remove is not found in the table.

Description by sleirsgoevy:

On PS4 FWs 9.00-9.04 the constructor returns with an exception, but to C++ code that ignores it. That is how an invalid font is created in the first place. On earlier PS4 FWs the exception is propagated to JavaScript.

==== 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://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)]

==== Patched ====
'''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.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.

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

==== Credits ====
* Quentin Meffre (@0xdagger) and Mehdi Talbi (@abu_y0ussef) who are Security Researcher at Synacktiv for fuzzing WebKit, finding a way to exploit the vulnerability on PS4, presenting it on Black Hat Europe 2020 ([https://www.blackhat.com/eu-20/briefings/schedule/index.html#this-is-for-the-pwners--exploiting-a-webkit--day-in-playstation--21212]) and sharing the code (2020-12-10)
* sleirsgoevy for porting (although with low success rate) to PS4 FWs 7.00-7.02

==== Analysis ====
* [https://github.com/WebKit/WebKit/commit/b99f0737d0bbcbc52c4b6e6edadcf4990173191f WebKit bad fix commit (2019-05-28)]
* [https://github.com/WebKit/WebKit/commit/b5d5412d9f517e25304aadb1b20dd5118a2c387d WebKit good fix commit (2020-09-11)]
* [https://www.synacktiv.com/publications/this-is-for-the-pwners-exploiting-a-webkit-0-day-in-playstation-4.html Write-up by Quentin Meffre (@0xdagger) and Mehdi Talbi (@abu_y0ussef) (2020-12-10)]
* [http://i.blackhat.com/eu-20/Thursday/eu-20-Meffre-This-Is-For-The-Pwners-Exploiting-A-Webkit-0day-In-Playstation4.pdf Presentation slides by by Quentin Meffre (@0xdagger) and Mehdi Talbi (@abu_y0ussef) (2020-12-10)]

==== Bug Description ====
* The method buildBubbleTree makes a call to update the layout during which all user registered JS handlers are executed. If the ValidationMessage is destroyed in a JS callback, this could lead to a Use-After-Free situation when we get back to buildBubbleTree code.

* ValidationMessage::buildBubbleTree is doing layout which can run a script detaching the owner form element, and this ValidationMessage object can be destroyed.

After private disclose by Synacktiv ethical hackers, the vulnerability was fixed in WebKit on September 11st 2020. SIE updated to the patched WebKit with firmware 8.00 released on October 14st 2020.

==== Exploit Implementation ====
* [https://github.com/synacktiv/PS4-webkit-exploit-6.XX Initial 6.xx implementation by Quentin Meffre (@0xdagger) and Mehdi Talbi (@abu_y0ussef) (2020-11-12]
* [https://github.com/sleirsgoevy/PS4-webkit-exploit-7.02 7.02 implementation with code execution by sleirsgoevy (2020-12-15)]
* [https://github.com/sleirsgoevy/ps4jb 6.72-7.02 Kernel exploit using this WebKit exploit by sleirsgoevy (2020-12-16)]
* [https://github.com/ChendoChap/ps4-ipv6-uaf/tree/7.00-7.02 7.00-7.02 Kernel exploit using this WebKit exploit by ChendoChap (2020-12-16)]

==== Patched ====
'''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.

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

==== Credits ====
* Lokihardt (from Google Project Zer0) for the exploit PoC (Sep 13, 2018)
* Fire30 for turning the vulnerability into exploit for PS4 (Dec 30, 2019)
* sleirsgoevy for attempting to stabilize the PS4 exploit with a new implementation (Feb 23, 2020)

==== Analysis ====
* https://bugs.chromium.org/p/project-zero/issues/detail?id=1665
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4386
* https://packetstormsecurity.com/files/155871/Sony-Playstation-4-Webkit-Code-Execution.html
* https://twitter.com/Fire30_/status/1211775229116211200

==== Bug Description ====
WebKit: JSC: BytecodeGenerator::hoistSloppyModeFunctionIfNecessary does not invalidate the ForInContext object.

It is possible to craft Javascript in such a way that allows for an object to be passed as the property variable directly as a string to the op_get_direct_pname handler without being properly validated.

This is a Type Confusion exploit.

==== Exploit Implementation ====
* [https://github.com/Fire30/bad_hoist Initial implementation by Fire30]
* [https://github.com/sleirsgoevy/bad_hoist Implementation with code execution by sleirsgoevy]

9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]
9,223,372,036,854,775,807javascript:[...Array(2**32-1)]
javascript:[...Array(2**32-1)]

=== FW 4.50-6.72 - DOMWindow::open heap UaF (CVE-2021-30849) leading to crash ===

==== Credits ====
* Sergei Glazunov (from Google Project Zer0) for the exploit PoC (Jul 1, 2021)

==== Analysis ====
* https://bugs.chromium.org/p/project-zero/issues/detail?id=2204

==== Bug Description ====

==== Exploit Implementation ====

==== Patched ====
'''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.
----

=== FW 4.50-6.20 - JSArray::shiftCountWithArrayStorage() OOB RW (CVE-2018-4441) leading to arbitrary RW ===

==== Credits ====
* Lokihardt (from Google Project Zer0) for the exploit PoC (Oct 3, 2018)
* Specter for the rewriting for PS4 (Mar 8, 2019)
* St4rk for helping Specter

==== Analysis ====
* [https://bugs.chromium.org/p/project-zero/issues/detail?id=1685 Bug report by Lokihardt (Oct 3, 2018)]
* [https://github.com/WebKit/webkit/commit/51a62eb53815863a1bd2dd946d12f383e8695db0 WebKit fix commit (Oct 15, 2018)]
* [https://mastodon.social/@buherator/101654714198519755 Announce of incoming write-up by rkmylo and buherator/stratan/@5tratan, Meligra Team (Feb 25, 2019)]
* [https://rstforums.com/forum/topic/110439-cve-2018-4441-oob-rw-via-jsarrayunshiftcountwitharraystorage-webkit/ Write-up mirrored by Nytro (Feb 27, 2019)]

==== Bug Description ====
We would take the fast path for JSArray::shiftCountWithArrayStorage when the array hasHoles(). However, the code for this was wrong. It would incorrectly update ArrayStorage::m_numValuesInVector.

==== Exploit Implementation ====
* [https://github.com/Cryptogenic/PS4-6.20-WebKit-Code-Execution-Exploit PS4 6.20 WebKit exploit by Specter]

==== Patched ====
'''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".
----

=== FW 6.00-6.20 - JSC::arrayProtoPrivateFuncConcatMemcpy() Information Leak (CVE-2018-4358) ?leading to ASLR defeat? ===

==== Credits ====
* bkth, niklasb and saelo (from phoenhex Team) for the exploit PoC in Safari (Sep 26, 2018)
* Vultra for discovering that the exploit worked on PS4 FW 6.00 (Dec 10, 2018)

==== Analysis ====
* Related: https://bugs.chromium.org/p/project-zero/issues/detail?id=1032
* Related: https://doar-e.github.io/blog/2018/07/14/cve-2017-2446-or-jscjsglobalobjectishavingabadtime/
* https://github.com/WebKit/webkit/commit/b68b373dcbfbc68682ceeca8292c5c0051472071
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4358
* https://phoenhex.re/2018-09-26/safari-array-concat

==== Bug Description ====

==== Exploit Implementation ====
* [https://github.com/externalist/exploit_playground/blob/master/jsc_ConcatMemcpy_infoleak/ileak.html PoC for iOS]
* [https://github.com/Josephmh97/PS4_jsc_ConcatMemcpy_POC PoC for PS4]

==== Patched ====
'''Yes''' in 6.50 FW

==== Tested ====
Works on 6.00-6.20. Not working on PS4 FWs <= 5.56 because JSC (JavaScriptCore) was too old.
----

=== FW 4.50-5.56 - JSGlobalObject::haveABadTime() Type Confusion (CVE-2017-7005) leading to arbitrary RW ===

==== Credits ====
* Lokihardt (from Google Project Zer0) for the exploit PoC (Mar 20, 2017)
* ALEXZZZ9 for the first PS4 implementation (on 5.01), and at same time for burning the exploit (Feb 20, 2018)
* qwertyoruiop for rewriting and porting to 5.05 and 5.50

==== Analysis ====
[https://bugs.chromium.org/p/project-zero/issues/detail?id=1208 Project Zer0 Bug Description]

==== Bug Description ====
When JSGlobalObject::haveABadTime() is called with arrays of a different JSGlobalObject type, type confusion can occur, leading to memory corruption.

==== Exploit Implementation ====
* [https://github.com/ALEXZZZ9/PS4-5.01-WebKit-Exploit-PoC]
* [http://crack.bargains/550/ PS4 5.50 (WebKit Only)]
* [https://github.com/Cryptogenic/PS4-5.05-Kernel-Exploit/blob/master/expl.js]

==== Patched ====
'''Yes''' in 6.00 FW
----

=== FW ?.??-4.05-5.56 - Document::adoptNode() UaF (CVE-2017-2468) leading to crash ===

==== Credits ====
* Lokihardt (from Google Project Zer0) for the exploit PoC (Jan 23, 2017)
* CelesteBlue for testing on PS4 and PS Vita (May 9, 2020)

==== Analysis ====
* [https://bugs.chromium.org/p/project-zero/issues/detail?id=1099 exploit report by Lokihardt (Jan 23, 2017)]
* [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2468 Mitre report]
* [https://www.exploit-db.com/exploits/41868 exploitDB report]
* [https://github.com/0xR0/uxss-db/tree/master/webkit/CVE-2017-2468 Mirror of report and PoC]
* [https://bugs.chromium.org/p/chromium/issues/detail?id=541206 Similar bug (CVE-2015-6770) with similar PoC (Oct 8, 2015)]

==== Bug Description ====

==== Exploit Implementation ====
* [https://github.com/Metnew/uxss-db/tree/master/webkit/CVE-2017-2468 PoC that just crashes on PS4 FW 4.05-5.56 and PS Vita FW 3.60]

==== Patched ====
'''Yes''' in 6.00 FW. Vulnerable at least on PS4 FWs 4.05-5.56 and PS Vita FW 3.60.
----

=== FW 4.50-5.56 - WebCore::HTMLFrameElementBase::marginHeight() Heap UaF (CVE-2016-1859) leading to arbitrary RW ===

==== Credits ====
* Liang Chen, wushi of KeenLab, Tencent working with Trend Micro's Zero Day Initiative for discovering this vulnerability (2016-03-16)

==== Analysis ====
* [https://nvd.nist.gov/vuln/detail/CVE-2016-1859 NVD description of CVE-2016-1859 (May 5, 2016)]
* [https://www.zerodayinitiative.com/advisories/ZDI-16-352/ ZDI advisory for CVE-2016-1859 (May 20, 2016)]
* [https://www.blackhat.com/docs/us-16/materials/us-16-Molinyawe-Shell-On-Earth-From-Browser-To-System-Compromise-wp.pdf Writeup by Matt Molinyawe, Abdul-Aziz Hariri, and Jasiel Spelman (Trend Micro) (August 1, 2016)]
* [http://arayz.github.io/933ky/A-general-attack-model-of-UAF-on-browser/ Writeup by Arayz (Wang Ao) (March 31, 2017)]
* [https://daehee87.github.io/data/ruma.pdf On the Analysis of Byte-Granularity Heap Randomization (October 24, 2019)]

==== Bug Description ====
The specific flaw exists within the handling of GraphicsContext objects. By manipulating a document's elements an attacker can force this object in memory to be reused after it has been freed. An attacker can leverage this vulnerability to execute code under the context of the current process.

CVE-2016-1859 is a use-after-free vulnerability that existed in the Safari web browser. A GraphicsContext object is used in the setPlatformTextDrawingMode function after it has been freed. The successful triggering of the use-after-free vulnerability itself does not allow the attacker to directly change the control flow or disclose arbitrary memory contents. However, the use-after-free yields an arbitrary-memory-write primitive by hijacking a destination pointer that will be used for the memcpy function. Once the arbitrary-memory-write primitive is achieved, the attacker sprays the heap with string objects to achieve the arbitrary-memory-read primitive. Relying on the pointer width heap alignment, the attacker can accurately predict the exact address of one of the string objects among the heap spray and pinpoint the address of member variable. At this point, the attacker can overwrite the length member variable of a string object and partially disclose the out-of-bound heap area exceeding the buffer address of the string. The partial disclosure of the heap memory allows the attacker to extend the information leak step-by-step and ultimately allows full chaining of ROP, which leads to arbitrary code execution.

==== Exploit Implementation ====
* PoC publicly available
* No full exploit publicly available but exploitation description is detailed

==== Patched ====
'''Yes''' in 6.00 FW. Vulnerable on PS4 FWs 4.50-5.56.
----

=== FW 4.50-5.01 - Element::setAttributeNodeNS() UaF leading to arbitrary RW ===

==== Credits ====
* Lokihardt (from Google Project Zer0) for the exploit PoC (Mar 15, 2017)
* qwertyoruiop for the PS4 exploit (October 2017)
* Specter for the writeup (May 27, 2018)

==== Analysis ====
* [https://bugs.chromium.org/p/project-zero/issues/detail?id=1187 exploit report by Lokihardt (Mar 15, 2017)]
* [https://twitter.com/VVildCard777/status/919843554964443137 First test on PS4 by WildCard (Oct 16, 2017)]
* [https://github.com/Cryptogenic/Exploit-Writeups/blob/master/WebKit/setAttributeNodeNS%20UAF%20Write-up.md Specter's setAttributeNodeNS Exploit Writeup]

==== Bug Description ====
By forcing setAttributeInternal() to call setAttributeNodeNS() twice, an attribute node reference will be added twice to the list. When one is free()'d, the second attribute still contains a duplicate stale reference, leading to a use-after-free (UAF) scenario. 

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

==== Patched ====
'''Yes''' in 5.03 FW.
----

=== FW 3.15-4.07 - Stack Uninitialized Read UaF leading to arbitrary RW ===

==== Credits ====
* qwertyoruiop for the exploit
* Specter for the writeup

==== Analysis ====
* [https://github.com/Cryptogenic/Exploit-Writeups/blob/master/PS4/4.0x%20WebKit%20Exploit%20Writeup.md Specter's 4.0x WebKit Exploit Writeup]

==== Bug Description ====
Via a specially crafted valueOf() function of an arguments.length() function, non-zero indexes of the stack-allocated array are not initialized, leading to a stack uninitialized read. This can be abused to store a reference that can later be re-obtained post-GC (garbage collection) yielding a use-after-free() (UAF) situation.

==== Exploit Implementation ====
* [https://github.com/Cryptogenic/PS4-4.0x-Code-Execution-PoC Specter's commented and usable version]
* [https://gist.github.com/X41/36acd2a6939e4cebbecba45d35bf0d75 mirrorred expl.js from qwertyoruiop]

==== Patched ====
'''Yes''' in 4.50 FW

==== Tested ====
Works on 3.15-4.07. Not working on <= 3.11.
----

=== FW 3.15-3.70 - JSArray::sortCompactedVector() Heap UaF leading to arbitrary RW ===

==== Credits ====
* xyz for the original exploit on PSVita (HENkaku)
* Fire30 for porting to PS4
* Specter for improved PS4 playground

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

==== Bug Description ====
When attempting to update a vector via sortCompactedVector() - data is written based on a pointer, though the pointer is not re-updated nor nulled. When this memory in free()'d, the reference is maintained and thus memory corruption can occur.

==== Exploit Implementation ====
* [https://github.com/henkaku/henkaku/blob/master/webkit/exploit.js PSVita 3.60 WebKit exploit by xyz]
* [https://github.com/Fire30/PS4-3.55-Code-Execution-PoC PS4 playground 3.15-3.70 by Fire30]
* [https://github.com/Cryptogenic/PS4-Playground-3.55 Improved PS4 playground 3.15-3.70 by Specter]

==== Patched ====
'''Yes''' in 4.0?0? FW

==== Tested ====
Works on 3.15-3.70. Not working on <= 3.11. Maybe working on 4.00.
----

=== FW <= 3.50 - WebCore::TimerBase::heapPopMin() Heap UaF leading to crash ===

==== Analysis ====
* [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]

==== Bug Description ====
"As of firmware version 3.55 a patch has been included to prevent a use-after-free segmentation fault from being exploited. This could have led to a ROP chain and code execution. It would have been cool if someone would have done some real research on it..." qwertyoruiop

==== Exploit Implementation ====
* [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 (21-05-2016)]
* [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 (07-2016)]
* [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]

==== Patched ====
'''Yes''' in 3.55 FW

==== Tested ====
Works on 3.15, 3.50 FW. Maybe working on 3.51 FW.
----

=== FW <= 2.03 - WebCore::CSSSelector Heap Overflow (CVE-2014-1303) leading to arbitrary RW ===

==== Credits ====
* KeenTeam for finding and documenting the bug
* Liang Chen from KeenTeam for the writeups
* xyz for porting to PSVita FWs 3.30-3.36
* Fire30 for porting to PS4
* dreadlyei (unknown person, credited by Fire30)

==== Analysis ====
* [https://www.blackhat.com/docs/eu-14/materials/eu-14-Chen-WebKit-Everywhere-Secure-Or-Not.PDF BlackHat EU 2014 'WebKit Everywhere - Secure Or Not?' slides]
* [https://www.blackhat.com/docs/eu-14/materials/eu-14-Chen-WebKit-Everywhere-Secure-Or-Not-WP.pdf BlackHat EU 2014 'WebKit Everywhere - Secure Or Not?' PDF]
* [https://cansecwest.com/slides/2015/Liang_CanSecWest2015.pdf Attacking WebKit Applications by exploiting memory corruption bugs by Liang Chen]

==== Bug Description ====
By forcing addRule() to be called on a CSS Selector via window.getMatchedCSSRules(), a 1-bit OOB write can be achieved and leveraged to corrupt heap memory.

==== Exploit Implementation ====
* [https://github.com/Fire30/PS4-2014-1303-POC ROP PoC for PS4 FW 2.03 by Fire30]
* [http://wololo.net/2016/04/21/proof-of-concept-webkit-exploit-running-on-ps4-firmwares-up wololo article]
* WebKit exploit for 3.30-3.36 FW PSVita by xyz: used in vitasploit
* [https://github.com/RKX1209/CVE-2014-1303 PoC for Linux by RKX1209]

==== Patched ====
'''Yes''' in 2.50 FW

==== Tested ====
* Working on 2.00-2.03 FW. Might work on 2.04 (99% sure as 2.04 PUP is about same size as 2.03 PUP).
* Working on AppleWebKit/537.73
* Maybe not working on FW < 2.00.
----

=== FW <= 2.03-? - WebCore::ImageInputType::attach Heap UaF (CVE-2013-2857) leading to ROP execution ===

==== Credits ====
* Chromium bugs reporters
* JumpCallPop, jam1garner, hedgeberg for inital exploit on Wii U
* yellows8 for ROP on Wii U
* orboditilt for increasing stability on Wii U
* zoogie for porting Wii U exploit to New3DS
* CelesteBlue for testing on PS4 FW 2.03

==== Analysis ====
* [https://bugs.chromium.org/p/chromium/issues/detail?id=240124 Chromium bug report with a PoC]

==== Bug Description ====
Use-after-free with input type image. Error event was fired synchronously blowing away the input element from underneath.

Exploiting this vulnerability on PS4 is not good because:
* This vulnerability does not provide arbitrary RW without code execution, hence ROP chain (at least to stack pivot to JiT code) must be made with a memory dump or decrypted modules for this FW gotten using another vulnerability.
* There is usermode ASLR since about FW 1.70 so ROP chain gadgets must be relocated at runtime. This means another vulnerability allowing usermode arbitrary read is needed.
* As usually an arbitrary read vulnerability also gives arbitrary write, and as arbitrary RW leads to usermode code execution (by hijacking JS pointers in virtual table), this UaF is not needed at all.
* Even if we get ROP chain to work on PS4 with this UaF vulnerability, there is no evidence that a return to JavaScript from ROP chain is doable, making this exploit less convenient than arbitrary RW exploits method of getting code execution then returning to usermode by restoring vtable.

==== Exploit Implementation ====
* [https://github.com/WiiUTest/JsTypeHax Initial Wii U implementation]
* [https://github.com/WiiUTest/JsTypeHax/blob/master/payload/exploit_WORKING.html Wii U stabler implementation (last update May 22, 2018)]
* [https://github.com/wiiu-env/JsTypeHax Wii U tabler implementation (last update Jan 13, 2019)]
* [https://github.com/Hiperhazz/wiiuexploit/blob/master/firmware/Exploit.html Wii U stabler implementation by Hiperhazz (last update May 26, 2020)]
* [https://github.com/zoogie/new-browserhax/blob/master/index.html New3DS implementation by zoogie (last update Aug 9, 2020)]

==== Patched ====
'''Yes''' in ? FW

==== Tested ====
* Working on 2.03 FW. Might work on 2.04 (99% sure as 2.04 PUP is about same size as 2.03 PUP).
----

=== FW <= 1.76 - JSArray::sort() Heap Overflow (CVE-2012-3748, PSA 2013-0903-1) leading to arbitrary RW ===

==== Credits ====

* 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 (Oct. 23, 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]

==== Analysis ====
* [https://packetstormsecurity.com/files/cve/CVE-2012-3748 CVE-2012-3748]
* [https://packetstormsecurity.com/files/123088/ PSA 2013-0903-1]
* [https://www.exploit-db.com/exploits/28081/ Exploit PoC by Vitaliy Toropov]

==== Bug Description ====
By forcing the compare function to reduce the size of the array, trailing items will be written out of bounds (OOB write), leading to heap memory corruption.

==== Exploit Implementation ====
* [http://wololo.net/talk/viewtopic.php?p=368577 first POC for 1.76 PS4 by nas and Proxima]
* [http://wololo.net/downloads/index.php/download/8230 mirror]
* [http://daxhordes.org/ps4_176/ps4_dump.html live test]
* [http://daxhordes.org/ps4_176/ps4_dump2.html livetest2]
* [http://daxhordes.org/ps4_176/ps4_rop2.html ROP2]
* [https://cturt.github.io/PS4-playground/ PS4 playground 1.76 by CTurt]
* [https://bitbucket.org/DaveeFTW/psvita-260-webkit/src/master/ PSVita 2.00-3.20 WebKit exploit]

==== Patched ====
'''Yes''' in 2.00 FW

==== Tested ====
* Working on 1.00-1.76 FW, AppleWebKit/531.3-536.26
* Might work on FW 0.930.020.

== Usermode securities ==

=== Usermode ASLR ===

* Very old firmwares (<= 1.05) do not have ASLR enabled, but it was introduced sometime before firmware 1.70. "Address Space Layout Randomization" (ASLR) is a security technique which causes the base addresses of modules to be different every time you start the PS4.
* To defeat usermode ASLR on FWs >=1.70, we can use the module imports table to find other modules address once we know SceWebkit2 address.

=== Module imports table cleaned before execution ===

* 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:
1. Chose a function (ex: __stack_chk_fail) imported from libkernel.sprx by libSceWebkit2.sprx

2. Read pointer contained at the address where the call is done

3. Substract to this pointer the offset of the function (ex: __stack_chk_fail) in LibKernel module

4. This result is LibKernel base address. This method works for any imported module.

For FW >= 6.00, for web applications, libkernel.sprx has been replaced by libkernel_web.sprx and libSceWebKit2 by libSceNKWebKit.sprx. libkernel.sprx is still used by other applications.

=== 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.
* 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs).

=== 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.
* 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.
* Workaround is to use ROP.

=== Syscalls removed ===

=== Syscall 0 disabled i.e Error Kernel: The application directly issues a syscall instruction (24) ===

* 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 ===

* On 4.70, bpfwrite() was stripped out of the kernel entirely to patch kernel vulnerability exploited in 4.55 kexploit.

=== 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.

=== 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 ===

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

=== 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.

== Kernel Exploits ==

=== 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.

==== 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)]

==== Bug Description ====
A malicious PPPoE server can cause denial-of-service or potentially remote code execution in kernel context on the PS4/PS5. 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).

==== 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)]

==== Patched ====
'''Yes''' in 11.02 FW
----

=== FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867) ===

==== Credits ====
* 2021-09-24 m00nbsd for finding the vulnerability
* 2022-05-04 martin of NetBSD for fixing the vulnerability publicly in NetBSD 8 and 9
* 2022-05-11 m00nbsd for disclosing the vulnerability publicly on HackerOne

==== Analysis ====
* [https://hackerone.com/reports/1350653 HackerOne report by m00nbsd (2021-09-24)]
* [http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2022-001.txt.asc NetBSD Security Advisory about CVE-2022-29867 (2022-05-04)]

==== Bug Description ====
The PlayStation 4 has a kernel PPPoE driver, that originates from NetBSD. This driver has a kernel heap overflow vulnerability, that an attacker can remotely trigger over the LAN, with the ability to control both the contents that are overflown and their sizes.

Extract of NetBSD 8.3 changelog:
<pre>
sys/net/if_pppoe.c			1.179

	pppoe(4): fix CVE-2022-29867 - discovery phase local network
	mbuf corruption.
	[martin, ticket #1740]

Do not allocate mbuf clusters when the caller (eroneously) asks
for more than MCLBYTES size, instead fail the allocation.

When we have received multiple PADO offer packets in the discovery
phase, do not combine tags from different packets. We are supposed
to pick one PADO packet and continue session establishment with that.

The second bug could cause code to trigger the first and create
invalid response packets and also overwrite data outside of
the allocated mbuf cluster.

Fixes CVE-2022-29867.
</pre>

Diff after fix commit in NetBSD 8:
<source lang="C">
--- src/sys/net/if_pppoe.c	2020/02/13 19:37:39	1.125.6.10
+++ src/sys/net/if_pppoe.c	2022/05/04 15:36:35	1.125.6.11
@@ -1,4 +1,4 @@
-/* $NetBSD: if_pppoe.c,v 1.125.6.10 2020/02/13 19:37:39 martin Exp $ */
+/* $NetBSD: if_pppoe.c,v 1.125.6.11 2022/05/04 15:36:35 sborrill Exp $ */
 
 /*-
  * Copyright (c) 2002, 2008 The NetBSD Foundation, Inc.
@@ -30,7 +30,7 @@
  */
 
 #include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: if_pppoe.c,v 1.125.6.10 2020/02/13 19:37:39 martin Exp $");
+__KERNEL_RCSID(0, "$NetBSD: if_pppoe.c,v 1.125.6.11 2022/05/04 15:36:35 sborrill Exp $");
 
 #ifdef _KERNEL_OPT
 #include "pppoe.h"
@@ -871,6 +871,10 @@ breakbreak:;
 			}
 			sc->sc_ac_cookie_len = ac_cookie_len;
 			memcpy(sc->sc_ac_cookie, ac_cookie, ac_cookie_len);
+		} else if (sc->sc_ac_cookie) {
+			free(sc->sc_ac_cookie, M_DEVBUF);
+			sc->sc_ac_cookie = NULL;
+			sc->sc_ac_cookie_len = 0;
 		}
 		if (relay_sid) {
 			if (sc->sc_relay_sid)
@@ -886,6 +890,10 @@ breakbreak:;
 			}
 			sc->sc_relay_sid_len = relay_sid_len;
 			memcpy(sc->sc_relay_sid, relay_sid, relay_sid_len);
+		} else if (sc->sc_relay_sid) {
+			free(sc->sc_relay_sid, M_DEVBUF);
+			sc->sc_relay_sid = NULL;
+			sc->sc_relay_sid_len = 0;
 		}
 		memcpy(&sc->sc_dest, eh->ether_shost, sizeof sc->sc_dest);
 		callout_stop(&sc->sc_timeout);
@@ -1313,6 +1321,9 @@ pppoe_get_mbuf(size_t len)
 {
 	struct mbuf *m;
 
+	if (len + sizeof(struct ether_header) > MCLBYTES)
+		return NULL;
+
 	MGETHDR(m, M_DONTWAIT, MT_DATA);
 	if (m == NULL)
 		return NULL;
</source>

==== Exploit Implementation ====
* PoC (poc.c) by m00nbsd not disclosed publicly

==== Patched ====
'''Yes''' in 9.03 FW according to Specter by diffing PS4 9.00 and 9.03 kernels
----

=== FW <= 9.00 - exFAT driver heap-based buffer overflow ===

==== Credits ====
* 2021-09-15 TheFloW for finding the vulnerability
* 2021-12-02 zecoxao for advicing to exploit the vulnerability after diffing PS4 9.00 and 9.03 kernels
* 2021-12-13 ChendoChap, Znullptr, Specter for PS4 9.00 kernel exploit implementation release

==== Analysis ====
* [https://twitter.com/notzecoxao/status/1466463051872448521 Vulnerability adviced by zecoxao for exploitation (2021-12-02)]
* [https://hackerone.com/reports/1340942 TheFloW's report on HackerOne (2021-09-15), disclosed on 2022-09-21]

==== Bug Description ====
The PS4 kernel exFAT driver has a heap-based buffer overflow vulnerability that can be triggered by inserting a malicious USB storage device in PS4 in addition to having usermode code execution. Exploitation requires to flash a crafted exFAT image to a common USB storage device.

==== Exploit Implementation ====
* [https://github.com/ChendoChap/pOOBs4 ChendoChap's implementation for PS4 9.00 (2021-12-13)]

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

=== FW <= 7.55 - IP6_EXTHDR_CHECK Double Free (CVE-2020-9892) ===

==== Credits ====
* 2019-09-15 tuexen for finding the FreeBSD vulnerability [https://reviews.freebsd.org/D21664]
* 2020-07-24 TheFloW for finding CVE-2020-9892 in XNU
* 2020-07-26 TheFloW for porting CVE-2020-9892 to PS4
* 2020-07-27 TheFloW for publishing publicly a PoC leading to code execution on XNU. [https://twitter.com/theflow0/status/1324687305018408961]
* 2021-01-12 TheFloW for disclosing publicly the PS4 vulnerability. [https://hackerone.com/reports/943231]
* 2021-01-20 sleirsgoevy for making a first working exploit for FreeBSD 9 [https://twitter.com/sleirsgoevy/status/1351689713564979200]
* 2021-03-03 sleirsgoevy for making a second working exploit for FreeBSD 9 [https://twitter.com/sleirsgoevy/status/1367098280736399368]
* 2021-03-12 sleirsgoevy for making the first public usable exploit for PS4 7.50-7.55 (https://twitter.com/sleirsgoevy/status/1370481212813348865)

==== Analysis ====
* [https://reviews.freebsd.org/D21664 Fix handling of Hop-by-Hop options over the loopback interface commits review (2019-09-15 to 2020-05-07)]
* [https://support.apple.com/en-us/HT211288 Apple iOS 13.6 and iPadOS 13.6 Security Update (2020-07-24)]
* [https://support.apple.com/en-us/HT211289 Apple macOS Catalina 10.15.6 Security Update (2020-07-24)]
* [https://hackerone.com/reports/943231 TheFloW's report of the exploit with undisclosed PS4 and FreeBSD 9 PoCs]
* [https://github.com/google/security-research/security/advisories/GHSA-gxcr-cw4q-9q78 TheFloW's writeup and PoC for XNU (2020-07-26)]
* [https://github.com/freebsd/freebsd-src/commit/68e0e5a673c5026c68dba62314a2e58ad1533cfd#diff-816eb9feee4ece60d3c6e8933a75baf4fcfbdce0284500d86ac80e24827a19c8 Vulnerability adviced by TheFloW for exploitation (2018-02-05)]

==== Bug Description ====
Memory corruption can be achieved by sending fragmented IPv6 packets to loopback interface due to poor and inconsistent use of IP6_EXTHDR_CHECK.

The macro IP6_EXTHDR_CHECK can free the mbuf if the packet is sent to loopback interface. This fact is not considered in dest6_input(), frag6_input() and more. For example in dest6_input(), the double pointer is not updated.

Hence, when parsing next headers, the mbuf can be free'd once again, leading to a double free which behaves like a use-after-free when we allocate mbuf's again.

Normally, this path would not be triggerable, because sending to loopback interface requires SOCK_RAW root privileges. However, for some reason on the PS4 SOCK_RAW sockets can be opened in Webkit process! Moreover, CelesteBlue confirmed that SOCK_RAW sockets can also be opened in PS4 Kit fSELF.

According to TheFloW, the reliability of the FreeBSD 9 PoC is very high, around 80%, whereas the PS4 PoC's is not very high, he guesses around 20%.

==== Exploit Implementation ====
* [https://github.com/google/security-research/security/advisories/GHSA-gxcr-cw4q-9q78 TheFloW's writeup and PoC for XNU (2020-07-27)]
* [https://gist.github.com/sleirsgoevy/ff591bfdc3a6f7573ed2388b018b31ec sleirsgoevy's first exploit PoC for FreeBSD 9 (2021-01-20)]
* [https://asciinema.org/a/385584 Demonstration video of sleirsgoevy's first exploit PoC for FreeBSD 9 (2021-01-20)]
* [https://gist.github.com/CelesteBlue-dev/de46d9e94823f0a6cf4b3b40ad635c14 Specter's kernel panic PoC for PS4 Web browser (2021-01-15)]
* [https://gist.github.com/CelesteBlue-dev/16303965ffea7e0a2c7c1d763cc721ec CelesteBlue's kernel panic PoC for PS4 Kit fSELF (2021-01-15)]
* [https://github.com/dayzerosec/PS4-Kernel-Exploit-Stream WiP exploit code by Specter and tihmstar (2021-02-24)]
* [https://gist.github.com/sleirsgoevy/35722572b0096f9acfd76a97b5678bed sleirsgoevy's second exploit PoC for FreeBSD 9 (2021-03-03)]
* [https://asciinema.org/a/396409 Demonstration video of sleirsgoevy's second exploit PoC for FreeBSD 9 (2021-03-03)]
* [https://github.com/sleirsgoevy/ps4jb2/blob/75x/src/jb.c sleirsgoevy's implementation for PS4 7.5x (2021-03-12)]
* [https://gist.github.com/Cryptogenic/448fd98813ab5a93182fb9620c013e17 Specter's implementation for FreeBSD 9 (2021-03-24)]

==== Patched ====
'''Yes''' in 8.00 FW
----

=== FW <= 7.02 - IPV6_2292PKTOPTIONS UaF (yielding arbitrary kernel R/W) (CVE-2020-7457) ===

==== Credits ====
* 2018-08-18 up to 2020-07-06 Fire30 for finding and keeping the vulnerability as a private 0day for it not to be patched by SIE. [https://twitter.com/Fire30_/status/1280228173888831490]
* 2020-07-06 TheFloW for publishing publicly a PoC leading to code execution on FreeBSD. [https://twitter.com/theflow0/status/1280224554393178122]
* sleirsgoevy and ChendoChap for porting the PoC to PS4 and chaining it with the 6.72 and 7.02 WebKit exploits.
* SIE for not patching this vulnerability on PS5 even when patched on PS4.
* TheFlow for announcing that PS5 kernel was exploited: [https://twitter.com/theflow0/status/1457362920501829636 TheFloW's PS5 kernel exploit announcement (2021-11-07)] and later that it was that same vulnerability that was present in PS5 FW 3.00-4.51.

==== Analysis ====
* [https://hackerone.com/reports/826026 TheFloW's hackerone report of the PS4 kernel exploit with a FreeBSD 9-12 PoC]
* [https://www.freebsd.org/security/advisories/FreeBSD-SA-20:20.ipv6.asc FreeBSD Security Advisory FreeBSD-SA-20:20.ipv6]
* [https://www.freebsd.org/security/patches/SA-20:20/ipv6.patch FreeBSD patch for FreeBSD-SA-20:20.ipv6]
* [https://hackerone.com/reports/1441103 TheFloW's hackerone report of the PS5 kernel exploit]

==== Bug Description ====
Due to missing locks in option IPV6_2292PKTOPTIONS of setsockopt, it is possible to race and free the struct ip6_pktopts buffer, while it is being handled by ip6_setpktopt. This structure contains pointers (ip6po_pktinfo) that can be hijacked to obtain arbitrary kernel R/W primitives. As a consequence, it is easy to have kernel code execution. This vulnerability is reachable from WebKit sandbox and is available in the latest FW, that is 7.02.

Another description: There is a race and use-after-free vulnerability in the FreeBSD kernel IPv6 socket handling. A missing synchronization lock in the `IPV6_2292PKTOPTIONS` option handling in `setsockopt` permits racing `ip6_setpktopt` access to a freed `ip6_pktopts` struct. This exploit overwrites the `ip6po_pktinfo` pointer of a `ip6_pktopts` struct in freed memory to achieve arbitrary kernel read/write.

==== Exploit Implementation ====
* [https://web.archive.org/web/20221114191136/https://hackerone-us-west-2-production-attachments.s3.us-west-2.amazonaws.com/Y13EyQCGKEqxH8PpJgFKh5uY?response-content-disposition=attachment%3B%20filename%3D%22exploit.c%22%3B%20filename%2A%3DUTF-8%27%27exploit.c&response-content-type=text%2Fx-c%2B%2Bsrc&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAQGK6FURQZUKBWFOX%2F20221114%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20221114T190929Z&X-Amz-Expires=3600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEOL%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLXdlc3QtMiJGMEQCIFEUV16y5O0IfDfbCmJ%2F6CNBjc6kmS%2BLdyYBPFSMIVMSAiADc6fvThSy0kmHFzOgAuurPiybfKCotgtPfJV7%2BW%2BFISrVBAjb%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F8BEAMaDDAxMzYxOTI3NDg0OSIMz0dZbvRJU9aGlVs8KqkENy%2FVEqF6TYz2HV%2F9sZELOz%2BpxTJWSgQJD3vCru6Qzggs8Xgdri4orYmQzZKvAvhNa2npS%2F86NUBQwqurS2QL5yc7Sb0ZZn%2FcJnIA%2BBsk5lwmZyKy8WAo4Lug8AtID3L8mD5RRFBojcoyIvpbxXHakUn95b%2F44fV4W%2BvufW9YhsYK1FuM%2F0B6bRNUec5ny%2Fqla1KwOnjv7SINSCxdufU8sC1zTQ9RFNsYtNsOMDFPOQAR%2FAXomotb63jvMJROdCkcvoGPfozkJjYg5atl3d44fO%2FSfyYteUZB%2BIJwchX1HlAVK2vxrPuO%2FJTN9XzJvQsHjJFluix9rxBPmpROxI%2Ffi6NuDs0I2uv0%2BvCuGRpqcSqtXUKc3TRb5nQoNUsJDcMF9hXRio37LorziEo6N5Q7sDsygd0vOq6lNQqMZh8gyOwSpcSfsE9U0uMTIUXV9in8%2BF4k3F%2FLH4HzRpDIPJaSm%2FBGKlrFiTXdVExPGYkgJHdEIPL%2FPykEOaS3JXXcZlTrV7QQEUuq5a4gEZad8WHShcDOHoOujd5GTJmpctChhpDI3SrXdH%2BN%2B4h2venOtXxjRoYKemEWa4LFrj7rvynFDv2jijqCHdkMnGJo3bdGns7rEdPaeHSyVZSiWAY1MWwuYFYRkZIxq%2BlILvy1Mitp%2FEe70ZQ63pmir99p8dGiOYNKe%2FFoJI6zZm4uYVa%2Fxuwf3sD8Je6plXBy4%2BaPzbkQ6EY5BxGr%2FSdMnzDTiMqbBjqqAZeQf4BVmDmE50Upkzo0uDY9tVuKTV7pmJ8dSXhwZbOE5bjaUYBn6fgRxYFOfSf3QX6u1VSnbyDicpmDYkt4yuz%2BU7R%2Bx68pJY1%2BQyb7aGRmVSrm7lrTwGqz%2BcsOohl6cwONvLgfHPhztGD1qDRbS2cjXGcF30AR1cS0LbLq6zax8x2SnH8MfnGoAY3KI%2FTMRRzWA7qMETPrAEWYzRgGzqLkk%2FddHKZBLC4U&X-Amz-SignedHeaders=host&X-Amz-Signature=4a8fe44640d605e3ea252fe41d6b7d83c72aa082c7eb17e3d11d85b32d609b50 TheFloW's PoC for FreeBSD 9 and 12]
* [https://github.com/sleirsgoevy/ps4jb PS4 6.72-7.02 WebKit + Kernel Exploit implementation by sleirsgoevy]
* [https://github.com/ChendoChap/ps4-ipv6-uaf PS4 5.05-7.02 WebKit + Kernel Exploit implementation by ChendoChap]

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

=== FW <= 5.07 - BPF Race Condition (Yielding Double Free()) ===

==== Analysis ====
[https://github.com/Cryptogenic/Exploit-Writeups/blob/master/FreeBSD/PS4%205.05%20BPF%20Double%20Free%20Kernel%20Exploit%20Writeup.md Specter's Writeup of the 5.05 BPF Race Condition]

==== Bug Description ====
Due to improper locking, two threads can enter the BPF SETWF ioctl command handler. While the bug is similar to that of 4.55, the method of attack is slightly different. Since write() was removed for BPF in 4.70, instead of triggering a use-after-free with write() - SETWF is ran in parallel via threading. Eventually, both calls will copy the same pointer to the stack, leading to both threads free()'ing the same pointer, poisoning the freelist. This can later be leveraged via heap spraying to corrupt heap memory to obtain arbitrary code execution in supervisor mode (ring0).

==== Exploit Implementation ====
* [http://crack.bargains/505k/ PS4 5.05 WebKit + Kernel Exploit]
* [https://github.com/Cryptogenic/PS4-5.05-Kernel-Exploit PS4 5.05 WebKit + Kernel Exploit Source]

==== Patched ====
'''Yes''' in 5.50 FW
----

=== FW <= 4.55 - BPF Race Condition (Yielding UaF) ===

==== Analysis ====
[https://github.com/Cryptogenic/Exploit-Writeups/blob/master/FreeBSD/PS4%204.55%20BPF%20Race%20Condition%20Kernel%20Exploit%20Writeup.md Specter's Writeup of the 4.55 BPF Race Condition]

==== Bug Description ====
Due to improper locking, two threads can enter the BPF ioctl command handlers for setting a new write filter (SETWF) and setting a filter (SETIF). Both threads will reference the same pointer. In specially crafted situations, one thread could free() this pointer while the other thread executes it as a filter post-validation. This allows an unprivileged user to obtain an out-of-bounds (OOB) write on the stack, leading to arbitrary code execution in supervisor mode (ring0).

==== Exploit Implementation ====
[http://crack.bargains/455/ PS4 4.55 WebKit + Kernel Exploit]<br/>
[https://github.com/Cryptogenic/PS4-4.55-Kernel-Exploit PS4 4.55 WebKit + Kernel Exploit Source]

==== Patched ====
'''Yes''' in 4.70 FW
----

=== FW <= 6.00 ?6.02? - sys_getcontext Information Leak (kASLR defeat) (CVE-2018-17155) ===

==== Analysis ====
* https://www.cvedetails.com/cve/CVE-2018-17155/
* coming soon by CelesteBlue

==== Bug Description ====
System call 421 or sys_getcontext() initializes the structure pointed at by ucp to the currently active context. The vulnerability is, some areas of memory copied out are not initialized, and thus the function leaks memory at certain spots. This vector was patched in 6.20, as now before the buffer is used it is initialized to 0 via bzero().

==== Exploit Implementation ====
* QuickHEN by CelesteBlue (v2 not released yet)
* KitHEN by CelesteBlue (not released yet)

==== Patched ====
'''Yes''' somewhere between 6.00 and 6.20 FW
----

=== FW <= 4.07 - sys_thr_get_ucontext Information Leak (kASLR defeat) ===

==== Analysis ====
[https://github.com/Cryptogenic/Exploit-Writeups/blob/master/PS4/%22NamedObj%22%204.05%20Kernel%20Exploit%20Writeup.md#vector-sys_thr_get_ucontext Specter's Writeup]

==== Bug Description ====
System call 634 or sys_thr_get_ucontext() allows to obtain information on a given thread. The vulnerability is, some areas of memory copied out are not initialized, and thus the function leaks memory at certain spots. This vector was patched in 4.50, as now before the buffer is used it is initialized to 0 via bzero().

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

==== Patched ====
'''Yes''' in 4.50 FW
----

=== FW <= 4.05 - NamedObj Type Confusion (Yielding UaF) ===

==== Credits ====
* Chaitlin Tech for having been the first to show they had pwned PS4 FW 4.01 at Geekpwn convention. (2016-10-24)
[https://www.youtube.com/watch?v=KLkKql31d44 official video], [https://twitter.com/ChaitinTech/status/790945929624948736 tweet 1], [https://twitter.com/ChaitinTech/status/790947840495267841 tweet 2], [https://twitter.com/ChaitinTech/status/790949072429428737 tweet 3] (2016-10-25)
* fail0verflow for the first writeup (2017-10-19)
* Specter for rewriting the exploit using a different object, and releasing it publicly (2017-12-27)

==== Analysis ====
* [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/%22NamedObj%22%204.05%20Kernel%20Exploit%20Writeup.md Specter's writeup on his 4.05 implementation] (2017-12-28)

==== Bug Description ====
Type confusion in the namedobj system once exploited can lead to an arbitrary free() allowing an attacker to craft a use-after-free() (UAF) situation to corrupt kernel memory. This can be leveraged to eventually obtain an arbitrary code execution primitive in supervisor mode (ring0).

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

==== Patched ====
'''Yes''' in 4.06 FW

==== 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.
----

=== FW <= 1.76 - dlclose Kernel Heap Overflow ===

==== Credits ====
* Discovered by CTurt.
* Privately implemented thanks to qwertyoruiop.
* CTurt published a writeup.
* The exploit was publicly implemented by kR105 and on another side by Zer0xFF and Bigboss (psxdev).

==== Analysis ====
[http://cturt.github.io/dlclose-overflow.html Analysis of sys_dynlib_prepare_dlclose PS4 kernel heap overflow (by CTurt with the help of qwertyoruiop)]

==== Bug Description ====
Integer overflow in the sys_dynlib_prepare_dlclose() system call can lead to a heap overflow causing memory corruption, allowing an attacker to obtain code execution in supervisor mode (ring0).

==== Exploit Implementation ====
[https://github.com/kR105/PS4-dlclose Public release by kR105]

==== Patched ====
'''Yes''' in 2.00 FW
----

=== FW <= 1.76 - BadIRET (CVE-2014-9322, CVE-2015-5675) ===

==== Credits ====
* Andy Lutomirski for CVE-2014-9322 (2014-11-22)
* Konstantin Belousov, Andrew Lutomirski for CVE-2015-5675 (2015-07-08)
* Adam Zabrocki (pi3) for asking CTurt to test CVE-2015-5675 on PS4 (2015-08-21) [https://twitter.com/Adam_pi3/status/634514173263769600], [https://twitter.com/Adam_pi3/status/641166271157960704]
* Volodymyr Pikhur for exploiting FreeBSD and PS4 in private (2015-09-24) [https://twitter.com/vpikhur/status/646925039103705088]
* CTurt for porting the exploit from FreeBSD 9 to PS4 (2015-12-06) [https://twitter.com/CTurtE/status/673581693207502849]

==== Analysis ====
* [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f442be2fb22be02cafa606f1769fa1e6f894441 Fix commit for Linux CVE-2014-9322 by Andy Lutomirski]
* [https://nvd.nist.gov/vuln/detail/CVE-2014-9322 NVD Bug Description for CVE-2014-9322]
* [https://web.archive.org/web/20171118232027/https://blogs.bromium.com/exploiting-badiret-vulnerability-cve-2014-9322-linux-kernel-privilege-escalation/ 2014-9322 analysis by Rafal Wojtczuk]
* [http://blog.pi3.com.pl/?p=509 CVE-2014-9322 analysis by Adam Zabrocki (pi3)]

* [http://seclists.org/oss-sec/2015/q3/66 CVE-2015-5675 PoC for FreeBSD by Konstantin Belousov, Andrew Lutomirski (2015-07-08)]
* [https://www.freebsd.org/security/advisories/FreeBSD-SA-15:21.amd64.asc FreeBSD security advisory by Konstantin Belousov, Andrew Lutomirski (2015-08-25)]

* [http://cturt.github.io/ps4-3.html Hacking the PS4, part 3 - Kernel exploitation (by CTurt) (2015-12-17]

==== Bug Description ====
Faults associated with the stack segment (SS) register are not handled properly, allowing unprivileged users to trigger an IRET instruction that accesses a GS Base from usermode memory, providing an attacker with a method of privilege escalation.

==== Exploit Implementation ====
* [https://www.exploit-db.com/exploits/36266 CVE-2014-9322 kernel panic PoC for Linux by Emeric Nasi (2015-03-04)]
* [https://github.com/RKX1209/CVE-2014-9322 CVE-2014-9322 exploit code for Linux by Ren Kimura (@RKX1209) (2017-07-19)]
* [https://www.exploit-db.com/exploits/44205 CVE-2014-9322 exploit code for Linux by Ren Kimura (@RKX1209) (2017-07-24)]
* [http://seclists.org/oss-sec/2015/q3/66 CVE-2015-5675 PoC for FreeBSD by Konstantin Belousov, Andrew Lutomirski (2015-07-08)]

==== Patched ====
'''Yes''' in 2.00 FW

=== FW ??? - setlogin Information Leak (CVE-2014-8476) ===

Warning: this has not been tested on PS4.

==== Credits ====
* Mateusz Guzik for finding the vulnerability
* Volodymyr Pikhur for advising to use this vulnerability at his Playstation 4 Rest Mode DEMO in REcon Brussels 2018
* Francisco Falcon for making a PoC on FreeBSD 8.4

==== Analysis ====
* [https://www.cvedetails.com/cve/CVE-2014-8476/ CVE details]
* [https://www.freebsd.org/security/advisories/FreeBSD-SA-14%3A25.setlogin.asc FreeBSD Security Advisories]

==== Bug Description ====
The setlogin function in FreeBSD 8.4 through 10.1-RC4 does not initialize the buffer used to store the login name, which allows local users to obtain sensitive information from kernel memory via a call to getlogin, which returns the entire buffer.

When setlogin(2) is called while setting up a new login session, the login name is copied into an uninitialized stack buffer, which is then copied into a buffer of the same size in the session structure. The getlogin(2) system call returns the entire buffer rather than just the portion occupied by the login name associated with the session.

An unprivileged user can access this memory by calling getlogin(2) and reading beyond the terminating NUL character of the resulting string. Up to 16 (FreeBSD 8) or 32 (FreeBSD 9 and 10) bytes of kernel memory may be leaked in this manner for each invocation of setlogin(2).

This memory may contain sensitive information, such as portions of the file cache or terminal buffers, which an attacker might leverage to obtain elevated privileges.

==== Exploit Implementation ====
* [https://sysexit.wordpress.com/2014/11/12/analysis-of-cve-2014-8476-a-freebsd-kernel-memory-disclosure-vulnerability/ PoC for FreeBSD 8.4 by Francisco Falcon]

==== Patched ====
?

== Kernel securities ==

=== Kernel ASLR ===

Since 3.50 FW, ASLR (Address Space Layout Randomization) has been enabled in PS4 kernel. This means that to properly exploit the kernel to escalate privileges, an information disclosure vulnerability will most likely be needed to defeat ASLR and locate the kernel in memory.

=== Kernel SMAP ===

PS4 APU does not support SMEP ("Supervisor Mode Execution Prevention") so there is no way it supports SMAP ("Supervisor Mode Access Prevention"). However, in PS4 5.0x FW and above, a sort of SMAP was added to the kernel to prevent exploiters from pivoting the kernel stack pointer (RSP) to usermode memory: attempting to do so would crash the system. Sony probably added checks into the scheduler to check the stack pointer (RSP) against usermode addresses when running in kernel context. A new exploitation strategy is needed to run kernel ROP chains because an exploiters now needs to get his kernel ROP chain inside kernel memory to be executed.

==== SMAP bypass method: JOP ====

To bypass PS4 SMAP, qwertyoruiop decided in his 5.05 PS4 kernel exploit to go with the method he used on the Apple iPhone 7 - essentially using JOP to push a bunch of stack frames onto the kernel stack, and memcpy()'ing the kernel ROP chain into RSP. qwertyoruiop explained: "JOP seems to work, but exploit is not reliable enough to repeat it multiple times implementing logic in-between (like on the FW 4.55 kernel bug where every primitive would re-exploit the bug). Using pure JOP logic would be long because of the need to find good instructions gadgets, and would vary a lot from a FW version to another. The strategy chosen is thread-safe and calling-convention aware, but most importantly pivot-less. We use JOP to implement a simple loop based on deref&branch logic. Every iteration runs a function prolog followed by a branch. This pushes lots of stack frames on stack, padding RSP. When loop is done, prepare call to memcpy with RDI = RSP, RSI = controlled pointer, RDX = (size of pushed stack frame * number of iterations - 1). We overwrite all fake frames but one with ROP. Memcpy will return into our first gadget, kickstarting the chain. At tail end of chain we just return into matching function epilog to resume clean execution by popping the one untouched frame. RSP never pivoted so PS4 successfully runs the kernel ROP chain."

* [https://github.com/kpwn/PS4-5.05-Kernel-Exploit/blob/9e97c398342ed6499a00fce0c081f7bf1efaaef1/kernel.js Detailed annotation of the PS4 5.05 kernel exploit by Specter]
* [[:File:02r0.pdf|Zero2Ring0 Slides by qwertyoruiop]] ([https://web.archive.org/web/20210116214117/http://crack.bargains/02r0.pdf Archive])
* [https://web.archive.org/web/20120512144251/https://marcoramilli.blogspot.com/2011/12/from-rop-to-jop.html From ROP to JOP article by Marco Ramilli]

==== SMAP bypass method: cli/sti ====

A PS4 SMAP bypass has been showed by sleirsgoevy in his 6.72 PS4 kernel exploit implementation. It consists in wrapping the main kernel ROP with cli/sti pair, which would prevent it from being preempted. This way the thread's CPU core will not run other kernel code during kernel ROP execution, and other cores have no way of detecting the stack pivot, so the mitigation is defeated.

* [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 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 ===

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
   a1b7c:       48 a9 00 00 01 00       test   rax,0x10000
   a1b82:       75 02                   jne    a1b86 <-- skip the next instruction if CR0.WP is not cleared
   a1b84:       0f 0b                   ud2    <-- #UD exception, causes a kernel panic
   a1b86:       c3                      ret 

Note that the check is after the write, to prevent a ROP gadget from pointing straight at the mov and skipping the verification.

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.


{{Reverse Engineering}}
<noinclude>
[[Category:Main]]
</noinclude>