Editing Vulnerabilities
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 101: | Line 101: | ||
== Usermode Exploits (Game Savedata) == | == 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) === | === PS4/PS5 PS2emu sandbox escape (mast1c0re) === | ||
Advantages of the PS4/PS5 PS2emu sandbox escape exploit over most WebKit exploits: | Advantages of the PS4/PS5 PS2emu sandbox escape exploit over most WebKit exploits: | ||
* Bigger kernel attack surface (more usermode privileges) versus WebKit very restricted and becoming more and more with firmware revisions. For example, the PS2emu process uses libkernel_sys, which supports nmount and so | * Bigger kernel attack surface (more usermode privileges) versus WebKit very restricted and becoming more and more with firmware revisions. For example, the PS2emu process uses libkernel_sys, which supports nmount and so mount of system partitions, whilst neither libkernel_web nor regular libkernel do. | ||
* 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions | * 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions | ||
* Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update | * Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update | ||
Line 266: | Line 160: | ||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
* [https://github.com/McCaulay/mast1c0re | * [https://github.com/McCaulay/mast1c0re (2023-02-18)] | ||
==== Patched ==== | ==== Patched ==== | ||
'''No''' as of PS4 FW | '''No''' as of PS4 FW 10.70 and PS5 FW 7.60. Using the game Okage Shadow King, the exploit should work starting from PS4 FW 3.15 and PS5 FW 1.00. | ||
== Usermode Exploits (BD-J) == | == Usermode Exploits (BD-J) == | ||
Line 291: | Line 173: | ||
* JIT enabled allowing to write a kernel exploit in C versus writing in assembly and JavaScript since around FW 2.00 | * JIT enabled allowing to write a kernel exploit in C versus writing in assembly and JavaScript since around FW 2.00 | ||
=== FW <= 10.71 - BD-JB2 - Path traversal sandbox escape by TheFloW === | === FW <=10.71 - BD-JB2 - Path traversal sandbox escape by TheFloW === | ||
==== Credits ==== | ==== Credits ==== | ||
Line 309: | Line 191: | ||
'''No''' as of PS4 FW 10.71 (maybe patched on PS4 FW 11.00). '''Yes''' on PS5 FW 8.00. | '''No''' as of PS4 FW 10.71 (maybe patched on PS4 FW 11.00). '''Yes''' on PS5 FW 8.00. | ||
=== FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW === | === FW <=9.00 - BD-JB - Five vulnerabilities chained by TheFloW === | ||
==== Credits ==== | ==== Credits ==== | ||
Line 348: | Line 230: | ||
== Usermode Exploits (WebKit) == | == Usermode Exploits (WebKit) == | ||
=== | === FW 6.00-9.50-?.?? - FrameLoader::loadInSameDocument UaF (CVE-2022-22620) leading to arbitrary RW === | ||
==== Credits ==== | ==== Credits ==== | ||
* Sergei Glazunov, Google Project Zero, for reporting the bug in 2013-01 and answering Maddie Stone's questions in 2022 (2013) | * Sergei Glazunov, Google Project Zero, for reporting the bug in 2013-01 and answering Maddie Stone's questions in 2022 (2013) | ||
* Maddie Stone, Google Project Zero, for sharing a write-up describing this vulnerability (2022-06-14) | * Maddie Stone, Google Project Zero, for sharing a write-up describing this vulnerability (2022-06-14) | ||
* | * Anonymous for making an OOM PoC for PS4 (2023-10-03) then making an arbitrary RW PoC for webkit-gtk and PS4 7.00-9.50 (2023-10-24) | ||
==== Analysis ==== | ==== Analysis ==== | ||
Line 417: | Line 245: | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
The History API allows access to (and modification of) a stack of the pages visited in the current frame, and these page states are stored as a | The History API allows access to (and modification of) a stack of the pages visited in the current frame, and these page states are stored as a SerializedScriptValue. The History API exposes a getter for state, and a method replaceState which allows overwriting the "most recent" history entry. | ||
The bug is that | The bug is that FrameLoader::loadInSameDocument takes the state as an argument (stateObject), but does not increase its reference count. Only a HistoryItem object holds a reference to the stateObject. loadInSameDocument can trigger a callback into user JavaScript through the onblur event. The user's callback can call replaceState to replace the HistoryItem's state with a new object, therefore dropping the only reference to the stateObject. When the callback returns, loadInSameDocument will still use this free'd object in its call to statePopped, leading to the use-after-free. | ||
When | When loadInSameDocument is called it changes the focus to the element its scrolling to. If we set the focus on a different element prior to loadInSameDocument running, the blur event will be fired on that element. Then we can free the stateObject by calling replaceState in the onblur event handler. | ||
The bug is triggered by <code>history.back()</code> with the target state whose URL contains a hash | The bug is related to the web browser History API and is triggered by <code>history.back()</code> with the target state whose URL contains a hash: | ||
<source lang="js"> | <source lang="js"> | ||
history.pushState("state1", "", location + "#foo"); // URL with a hash | |||
// ... | |||
history.back(); // triggers loadInSameDocument() | |||
</source> | |||
The user may then trigger a double free and escalate it into an arbitrary read primitive. The exploit proceeds similarly to the buildBubbleTree() UaF exploit except the arbitrary decrement primitive is achieved from manipulating ~SerializedScriptValue(). | |||
A way to know if the system is vulnerable is the appearance of the input HTML element the PoC page after the timeout. If the HTML input field stays focused (blue outline) after second timeout, then the vulnerability is not present. Note that Maddie Stone's PoC will never trigger any sort of crash on release builds as it was meant for builds with memory sanitation that can detect UaFs. | |||
By default, arguments to functions should be reference-counted. Raw pointers should only be used in rare exceptions. | |||
The bug was killed in 2013 and re-introduced in 2016. It seems that this likely occured due to the large issues affecting most software dev teams: legacy code, short reviewer turn-around expectations, refactoring and security efforts are generally under-appreciated and under-rewarded, and lack of memory safety mitigations. Steps towards any of these would likely make a difference. | |||
The | |||
The | The two commits that reverted the 2013 fix were very, very large commits: 40 and 94 files changed. While some large commits may include exclusively no-ops, these commits included many changes affecting lifetime semantics. This seems like it would make it very difficult for any developer or reviewer to be able to truly audit and understand the security impacts of all the changes being made. | ||
This bug was actually reported and initially fixed in 2013. In 2016 the fix was regressed during (it seems) refactoring. It seems reasonable that the vulnerability could have been found through watching the commits and seeing the initial fix from 2013 reverted in 2016, code auditing, or fuzzing. Fuzzing seems slightly less likely due to needing to support "navigation" which many fuzzers explicitly try to exclude. | |||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
* Simple PoC for ASAN webkit-gtk by Maddie Stone in Maddie Stone's writeups | * Simple PoC for ASAN webkit-gtk by Maddie Stone in Maddie Stone's writeups | ||
* [https://github.com/springsec/CVE-2022-22620/blob/main/CVE-2022-22620_infoleak_exploit.html Information leak PoC for webkit-gtk by springsec] | * [https://github.com/springsec/CVE-2022-22620/blob/main/CVE-2022-22620_infoleak_exploit.html Information leak PoC for webkit-gtk by springsec] | ||
* [https://discord.com OOM PoC for PS4 | * [https://discord.com OOM PoC for PS4 by anonymous on ps4-dev discord (to mirror)] | ||
* [https://discord.com Arbitrary RW PoC | * [https://discord.com Arbitrary RW PoC for PS4 7.00-9.50 by anonymous on ps4-dev discord (to mirror)] | ||
==== Patched ==== | ==== Patched ==== | ||
''' | '''Maybe''' on PS4 FW 10.00 and '''Maybe''' on PS5 FW 4.51. | ||
The patch changes the stateObject argument to loadInSameDocument from a raw pointer, SerializedScriptValue*, to a reference-counted pointer, RefPtr<SerializedScriptValue>, so that loadInSameDocument now increments the reference count on the object. | The patch changes the stateObject argument to loadInSameDocument from a raw pointer, SerializedScriptValue*, to a reference-counted pointer, RefPtr<SerializedScriptValue>, so that loadInSameDocument now increments the reference count on the object. | ||
Tested working on PS4 FWs 6.00-9. | Tested working on PS4 FWs 6.00-9.50 and PS5 FWs none. Untested: every PS5 FWs. PS4 FWs <=5.56 seems invulnerable as the HTML input field stays focused (blue outline) after second timeout whilst it should not if the console were exploitable. PS4 FWs 6.00-6.72 pass the OOM PoC but "fail string leak" in the arbitrary RW PoC. | ||
=== FW 9.00-9.04 - WebCore::CSSFontFaceSet vulnerabilities leading to arbitrary RW === | === FW 9.00-9.04 - WebCore::CSSFontFaceSet vulnerabilities leading to arbitrary RW === | ||
Line 752: | Line 563: | ||
==== Tested ==== | ==== Tested ==== | ||
Works on 3.15-4.07. Not working on <= 3.11. | Works on 3.15-4.07. Not working on <=3.11. | ||
---- | ---- | ||
Line 802: | Line 613: | ||
==== Tested ==== | ==== Tested ==== | ||
Works on 3.15, 3.50 FW. Maybe working on 3.51 FW. | Works on 3.15, 3.50 FW. Maybe working on 3.51 FW. | ||
---- | ---- | ||
Line 940: | Line 725: | ||
=== Module imports table cleaned before execution === | === Module imports table cleaned before execution === | ||
* Between 1.76 and 4.05, Sony did that to prevent | * Between 1.76 and 4.05, Sony did that to prevent webkit exploiters from defeating usermode ASLR easily. | ||
* Now we have to dump entire usermode sandboxed memory, and by studying it we can defeat ASLR: | * Now we have to dump entire usermode sandboxed memory, and by studying it we can defeat ASLR: | ||
1. Chose a function (ex: __stack_chk_fail) imported from | 1. Chose a function (ex: __stack_chk_fail) imported from LibKernel by SceWebkit2 | ||
2. Read pointer contained at the address where the call is done | 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 | 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. | 4. This result is LibKernel base address. This method works for any imported module. | ||
=== DEP / NX === | === DEP / NX === | ||
* "Data Execution Prevention" / "No eXecute" is enabled on all firmwares. It prevents allocating memory as both RW and RX at same time (RWX) so preventing us from writing shellcode to usermode memory then executing it. | * "Data Execution Prevention" / "No eXecute" is enabled on all firmwares. It prevents allocating memory as both RW and RX at same time (RWX) so preventing us from writing shellcode to usermode memory then executing it. | ||
* 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs). | * 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs). | ||
=== JiT removed from webbrowser === | === JiT removed from webbrowser === | ||
* On FW <= 1.76, you could map RWX memory from ROP by abusing the JiT functionality and the sys_jitshm_create and sys_jitshm_alias system calls. This however was fixed after 1.76, as WebKit has been split into two processes. One handles javascript compilation and the other handles other web page elements like image rendering and DOM. The second process will request JiT memory upon hitting JavaScript via IPC (Inter-Process Communication). Since we no longer have access to the process responsible for JiT, we can no longer (at least currently), map RWX memory for proper code execution unless the kernel is patched. | * On FW <= 1.76, you could map RWX memory from ROP by abusing the JiT functionality and the sys_jitshm_create and sys_jitshm_alias system calls. This however was fixed after 1.76, as WebKit has been split into two processes. One handles javascript compilation and the other handles other web page elements like image rendering and DOM. The second process will request JiT memory upon hitting JavaScript via IPC (Inter-Process Communication). Since we no longer have access to the process responsible for JiT, we can no longer (at least currently), map RWX memory for proper code execution unless the kernel is patched. | ||
* Workaround is to use ROP. | * Workaround is to use ROP. | ||
=== Syscalls removed === | === Syscalls removed === | ||
=== Syscall 0 disabled i.e Error Kernel: The application directly issues a syscall instruction (24) === | === Syscall 0 disabled i.e Error Kernel: The application directly issues a syscall instruction (24) === | ||
Line 978: | Line 753: | ||
=== bpf_open function blocked for unprivileged processes === | === bpf_open function blocked for unprivileged processes === | ||
* On 5.50, opening BPF has been blocked for unprivileged processes such as WebKit and other apps/games. It's still present in the sandbox, however attempting to open it will fail and yield EPERM. This aims blocking BPF kernel exploits especially qwertyoruiop's BPF double free UAF. | * On 5.50, opening BPF has been blocked for unprivileged processes such as WebKit and other apps/games. It's still present in the sandbox, however attempting to open it will fail and yield EPERM. This aims blocking BPF kernel exploits especially qwertyoruiop's BPF double free UAF. | ||
=== bpf_ioctl function blocked or removed === | === bpf_ioctl function blocked or removed === | ||
* Moreover, on FW 5.50+, opening BPF is still possible in less sandboxed apps like test/devkits fselfs. But this is useless because ioctl does not work. | |||
* | |||
=== Device access blocked/removed from webbrowser === | === Device access blocked/removed from webbrowser === | ||
* Around 6.50-6.70, device access got blocked or removed. Now you can no longer access devices from | * Around 6.50-6.70, device access got blocked or removed. Now you can no longer access devices from webbrowser | ||
== Kernel Exploits == | == Kernel Exploits == | ||
=== FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867) === | === FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867) === | ||
Line 1,137: | Line 878: | ||
==== Patched ==== | ==== Patched ==== | ||
'''Yes''' in PS4 9.03 FW and PS5 4.50 FW | '''Yes''' in PS4 9.03 FW and PS5 4.50 FW. | ||
---- | ---- | ||
Line 1,303: | Line 1,044: | ||
==== Tested ==== | ==== Tested ==== | ||
Works on FWs 4.00-4.05. On <= 3.70 FW we have not found a way to leak the target object, but it might be doable as Fail0verflow did it on 1.01. | Works on FWs 4.00-4.05. On <=3.70 FW we have not found a way to leak the target object, but it might be doable as Fail0verflow did it on 1.01. | ||
---- | ---- | ||