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 103: | Line 103: | ||
=== PS2 games savedata exploits === | === PS2 games savedata exploits === | ||
==== GTA III ==== | |||
* [https://github.com/halpz/re3/blob/9a7fa478578beaba947ea867c15a25e411d641d8/src/save/MemoryCard.cpp#L358 vulnerability] | |||
* | |||
The game does a copy from the memory card into a fixed-size buffer with size supplied by the savedata. | |||
==== Dark Cloud ==== | |||
* [https://www.youtube.com/results?search_query=%22dark+cloud%22+item+glitch+menu+before%3A2008-01-01 video of bug triggering] | |||
Moving the cursor and pressing X on the same frame in the items menu allows us to pick up an item from out-of-bounds memory, which results in exploitable behaviour. | |||
==== Okage Shadow King ==== | |||
===== Credits ===== | |||
* CTurt for discovering these vulnerabilities in September 2021. | |||
* CTurt for public disclosure [https://twitter.com/CTurtE/status/1570189920844804097 on twitter] https://twitter.com/CTurtE/status/1570189920844804097(2022-09-14) | |||
* flatz, balika011, theflow0, chicken(s), PlayStation for helping CTurt | |||
* McCaulay for sharing publicly his implementation in February 2023. | |||
===== 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 205: | Line 160: | ||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
* [https://github.com/McCaulay/mast1c0re | * [https://github.com/McCaulay/mast1c0re (2023-02-18)] | ||
==== Patched ==== | ==== Patched ==== | ||
'''No''' as of PS4 FW 11. | '''No''' as of PS4 FW 11.00 and PS5 FW 8.00. Using the game Okage Shadow King, the exploit should work starting from PS4 FW 3.15 and PS5 FW 1.00. | ||
== Usermode Exploits (BD-J) == | == Usermode Exploits (BD-J) == | ||
| Line 848: | Line 791: | ||
=== Module imports table cleaned before execution === | === Module imports table cleaned before execution === | ||
* Between 1.76 and 4.05, Sony did that to prevent | * Between 1.76 and 4.05, Sony did that to prevent webkit exploiters from defeating usermode ASLR easily. | ||
* Now we have to dump entire usermode sandboxed memory, and by studying it we can defeat ASLR: | * Now we have to dump entire usermode sandboxed memory, and by studying it we can defeat ASLR: | ||
1. Chose a function (ex: __stack_chk_fail) imported from libkernel.sprx by libSceWebkit2.sprx | 1. Chose a function (ex: __stack_chk_fail) imported from libkernel.sprx by libSceWebkit2.sprx | ||
| Line 861: | Line 804: | ||
=== DEP / NX === | === DEP / NX === | ||
* "Data Execution Prevention" / "No eXecute" is enabled on all firmwares. It prevents allocating memory as both RW and RX at same time (RWX) so preventing us from writing shellcode to usermode memory then executing it. | * "Data Execution Prevention" / "No eXecute" is enabled on all firmwares. It prevents allocating memory as both RW and RX at same time (RWX) so preventing us from writing shellcode to usermode memory then executing it. | ||
* 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs). | * 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs). | ||
=== JiT removed from webbrowser === | === JiT removed from webbrowser === | ||
* On FW <= 1.76, you could map RWX memory from ROP by abusing the JiT functionality and the sys_jitshm_create and sys_jitshm_alias system calls. This however was fixed after 1.76, as WebKit has been split into two processes. One handles javascript compilation and the other handles other web page elements like image rendering and DOM. The second process will request JiT memory upon hitting JavaScript via IPC (Inter-Process Communication). Since we no longer have access to the process responsible for JiT, we can no longer (at least currently), map RWX memory for proper code execution unless the kernel is patched. | * On FW <= 1.76, you could map RWX memory from ROP by abusing the JiT functionality and the sys_jitshm_create and sys_jitshm_alias system calls. This however was fixed after 1.76, as WebKit has been split into two processes. One handles javascript compilation and the other handles other web page elements like image rendering and DOM. The second process will request JiT memory upon hitting JavaScript via IPC (Inter-Process Communication). Since we no longer have access to the process responsible for JiT, we can no longer (at least currently), map RWX memory for proper code execution unless the kernel is patched. | ||
* Checking the source code at [https://doc.dl.playstation.net/doc/ps4-oss/webkit.html ps4-oss], starting as early as FW 6.00, ENABLE_JIT=OFF for -DPORT=PlayStation4. It means that JIT functionality is completely removed from WebKit and there is no JIT coprocess that is allowed to request RWX memory to even attack. Even if there are JIT bugs that can lead us to request RWX memory in other platforms, we can't on the PS4 as there is no longer any JIT process. Unchecked all source codes, JIT process could have been removed earlier than 6.00. All exploits must use ROP. | * Checking the source code at [https://doc.dl.playstation.net/doc/ps4-oss/webkit.html ps4-oss], starting as early as FW 6.00, ENABLE_JIT=OFF for -DPORT=PlayStation4. It means that JIT functionality is completely removed from WebKit and there is no JIT coprocess that is allowed to request RWX memory to even attack. Even if there are JIT bugs that can lead us to request RWX memory in other platforms, we can't on the PS4 as there is no longer any JIT process. Unchecked all source codes, JIT process could have been removed earlier than 6.00. All exploits must use ROP. | ||
| Line 872: | Line 813: | ||
=== 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 886: | Line 825: | ||
=== 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 | ||
=== | === WebKit implements pointer poisoning for 6.xx firmwares === | ||
* For select types implemented by WebKit (such as JSC::JSFunction), certain pointer fields are XOR'ed by a cryptographic key generated at runtime. The key is generated once every process launch, one must recover it to unpoison the pointers. | * For select types implemented by WebKit (such as JSC::JSFunction), certain pointer fields are XOR'ed by a cryptographic key generated at runtime. The key is generated once every process launch, one must recover it to unpoison the pointers. | ||
== Kernel Exploits == | == Kernel Exploits == | ||
=== FW <= ?11.52? - umtx UaF (yielding arbitrary kernel R/W) (CVE-2024-43102) === | |||
==== Credits ==== | |||
* Rebecca Cran for discovering the bug in umtx (2023-05-07) | |||
* Synacktiv for finding and disclosing publicly the vulnerability (2024-09-04) | |||
* Olivier Certner for fixing the bug (2024-09-04), kib for reviewing the bug fix (2024-09-04), Ed Maste for approving the bug fix commit (2024-09-04) | |||
==== Analysis ==== | |||
* [https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271300 Crash report by Rebecca Cran (2023-05-07)] | |||
* [https://www.freebsd.org/security/advisories/FreeBSD-SA-24:14.umtx.asc FreeBSD Security Advisory for CVE-2024-43102 (2024-09-04)] | |||
* [https://cgit.freebsd.org/src/commit/?id=62f40433ab47ad4a9694a22a0313d57661502ca1 Fix commit (2024-09-04)] | |||
* [https://securityonline.info/freebsd-issues-urgent-security-advisory-for-cve-2024-43102-cvss-10/ Vulnerability press release (2024-09-09)] | |||
==== Bug Description ==== | |||
The _umtx_op(2) system call provides support for the implementation of synchronization primitives between threads, and is used by the 1:1 Threading Library (libthr, -lthr) to implement IEEE Std 1003.1-2001 (POSIX.1-2001) pthread locks, like mutexes, condition variables and so on. In particular, its UMTX_OP_SHM operation provides support for anonymous shared memory associated to a particular physical address, which is used to implement process-shared mutexes (PTHREAD_PROCESS_SHARED). | |||
Concurrent removals of such a mapping by using the UMTX_SHM_DESTROY sub-request of UMTX_OP_SHM can lead to decreasing the reference count of the object representing the mapping too many times, causing it to be freed too early. | |||
umtx_shm_unref_reg_locked() would unconditionally drop the "registry" reference, tied to USHMF_LINKED. | |||
This is not a problem for caller umtx_shm_object_terminated(), which operates under the 'umtx_shm_lock' lock end-to-end, but it is for indirect caller umtx_shm(), which drops the lock between umtx_shm_find_reg() and the call to umtx_shm_unref_reg(true) that deregisters the umtx shared region (from 'umtx_shm_registry'; umtx_shm_find_reg() only finds registered shared mutexes). | |||
Thus, two concurrent user-space callers of _umtx_op() with UMTX_OP_SHM and flags UMTX_SHM_DESTROY, both progressing past umtx_shm_find_reg() but before umtx_shm_unref_reg(true), would then decrease twice the reference count for the single reference standing for the shared mutex's registration. | |||
A malicious code exercizing the UMTX_SHM_DESTROY sub-request in parallel can panic the kernel or enable further Use-After-Free attacks, potentially including code execution or Capsicum sandbox escape. | |||
==== Exploit Implementation ==== | |||
* No implementation for now. | |||
==== Patched ==== | |||
'''Maybe'''. PS4 is maybe not affected even though PS5 is. A PoC and/or code diff is required to confirm that PS4 is not vulnerable. | |||
---- | |||
=== FW <= 11.00 - Remote vulnerabilities in spp (yielding kernel ASLR defeat) (CVE-2006-4304 and no-CVE) === | === FW <= 11.00 - Remote vulnerabilities in spp (yielding kernel ASLR defeat) (CVE-2006-4304 and no-CVE) === | ||