- 1 Hardware Exploits
- 2 WebKit/Userland Exploits
- 2.1 FW 6.00-6.72 - bad_hoist exploit (CVE-2018-4386)
- 2.2 FW 6.00-6.20 - JSArray::shiftCountWithArrayStorage() OOB RW (CVE-2018-4441)
- 2.3 FW 6.00-?6.20? - JSC::arrayProtoPrivateFuncConcatMemcpy() Information Leak (CVE-2018-4358)
- 2.4 FW 4.50-5.56 - JSGlobalObject::haveABadTime() Type Confusion (CVE-2017-7005)
- 2.5 FW 5.05 - Document::adoptNode UaF (only crash for now)
- 2.6 FW 5.05 - CVE-2016-1859
- 2.7 FW 4.50-5.01 - Element::setAttributeNodeNS UAF
- 2.8 FW 3.15-4.07 - Stack Uninitialized Read UAF
- 2.9 FW 3.15-3.70 - JSArray::sortCompactedVector() Heap UAF
- 2.10 FW <= 3.50 - WebCore::TimerBase::heapPopMin Heap UAF (only crash for now)
- 2.11 FW <= 2.03-? - WebCore::ImageInputType::attach Heap UaF (CVE-2013-2857)
- 2.12 FW <= 1.76 - JSArray::sort() Heap Overflow (CVE-2012-3748, PSA 2013-0903-1)
- 3 Userland securities
- 3.1 Userland ASLR
- 3.2 Module imports table cleaned before execution
- 3.3 DEP / NX
- 3.4 JiT removed from webbrowser
- 3.5 Syscalls removed
- 3.6 Syscall 0 disabled i.e Error Kernel: The application directly issues a syscall instruction (24)
- 3.7 bpf_write function stripped out of the kernel
- 3.8 bpf_open function blocked for unprivileged processes
- 3.9 bpf_ioctl function blocked or removed
- 3.10 Device access blocked/removed from webbrowser
- 4 Kernel Exploits
- 4.1 FW <= 7.02 - IPV6_2292PKTOPTIONS UaF (yielding arbitrary kernel R/W)
- 4.2 FW <= 5.07 - BPF Race Condition (Yielding Double Free())
- 4.3 FW <= 4.55 - BPF Race Condition (Yielding UaF)
- 4.4 FW <= 6.00 ?6.02? - sys_getcontext Information Leak (kASLR defeat)
- 4.5 FW <= 4.07 - sys_thr_get_ucontext Information Leak (kASLR defeat)
- 4.6 FW <= 4.05 - NamedObj Type Confusion (Yielding UaF)
- 4.7 FW <= 1.76 - dlclose Kernel Heap Overflow
- 4.8 FW <= 1.76 - BadIRET
- 5 Kernel securities
PCIe man-in-the-middle attack
- First done on 1.01 by failoverflow on PS4 launch !
- Detailed at 33c3: 33c3 slides by Marcan
- Permits kernel and userland dumping
It is possible to glitch the syscon debug interface to allow access and dump keys. Originally done by an anonymous member of fail0verflow.
Aeolia side channel analysis with differential power analysis has been shown to be able to recover key material on all PS4 models. 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.
FW 6.00-6.72 - bad_hoist exploit (CVE-2018-4386)
- 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)
WebKit: JSC: BytecodeGenerator::hoistSloppyModeFunctionIfNecessary doesn't invalidate the ForInContext object.
This is a Type Confusion exploit.
Yes in 7.00 FW
FW 6.00-6.20 - JSArray::shiftCountWithArrayStorage() OOB RW (CVE-2018-4441)
- 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
- Bug report by Lokihardt (Oct 3, 2018)
- WebKit fix commit (Oct 15, 2018)
- Announce of incoming write-up by rkmylo and buherator/stratan/@5tratan, Meligra Team (Feb 25, 2019)
- Write-up by Nytro, Meligra Team (Feb 27, 2019)
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.
Yes in 6.50 FW
FW 6.00-?6.20? - JSC::arrayProtoPrivateFuncConcatMemcpy() Information Leak (CVE-2018-4358)
- bkth, niklasb and saelo (from phoenhex Team) for the exploit PoC in Safari (Sep 26, 2018)
- Vultra for discovering that the exploit worked since FW 6.00 (Dec 10, 2018)
Yes in 6.50/1 FW
FW 4.50-5.56 - JSGlobalObject::haveABadTime() Type Confusion (CVE-2017-7005)
- 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
When JSGlobalObject::haveABadTime() is called with arrays of a different JSGlobalObject type, type confusion can occur, leading to memory corruption.
Yes in 6.00 FW
FW 5.05 - Document::adoptNode UaF (only crash for now)
- Lokihardt (from Google Project Zer0) for the exploit PoC (Jan 23, 2017)
- CelesteBlue for testing on PS4 and PSVita
- exploit report by Lokihardt (Jan 23, 2017)
- mitre report
- exploitDB report
- related bug (Oct 8, 2015)
- Test on PSVita FW 3.60 by CelesteBlue (May 9, 2020)
- Test on PS4 FW 5.05 by CelesteBlue (Aug 20, 2020)
Maybe in ?6.00? FW.
FW 5.05 - CVE-2016-1859
It crashes the webbrowser. Maybe that means that it's working.
FW 4.50-5.01 - Element::setAttributeNodeNS UAF
- 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)
- exploit report by Lokihardt (Mar 15, 2017)
- First test on PS4 by WildCard (Oct 16, 2017)
- Specter's setAttributeNodeNS Exploit Writeup
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.
Yes in 5.03 FW.
FW 3.15-4.07 - Stack Uninitialized Read UAF
- qwertyoruiop for the exploit
- Specter for the writeup
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.
Yes in 4.50 FW
Works on 3.15-4.07. Not working on <=3.11.
FW 3.15-3.70 - JSArray::sortCompactedVector() Heap UAF
- xyz for the original exploit on PSVita (HENkaku)
- Fire30 for porting to PS4
- Specter for improved PS4 playground
When attempting to update a vector via sortCompactedVector() - data is written based on a pointer, though the pointer isn't re-updated nor nulled. When this memory in free()'d, the reference is maintained and thus memory corruption can occur.
- PSVita 3.60 webkit exploit by xyz
- PS4 playground 3.15-3.70 by Fire30
- Improved PS4 playground 3.15-3.70 by Specter
Yes in 4.0?0? FW
Works on 3.15-3.70. Not working on <= 3.11. Maybe working on 4.00.
FW <= 3.50 - WebCore::TimerBase::heapPopMin Heap UAF (only crash for now)
"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..."
- Article about qwertyoruiop's tests (20-05-2016)
- Article about initial PoC for PS4 (21-05-2016)
- Initial PoC for PS4 (21-05-2016)
- iOS 9.3.2 WebKit RCE via heapPopMin (07-2016)
- qwertyoruiop's tweet (22-07-2016)
- mirror of iOS 9.3.2 WebKit RCE via heapPopMin
Yes in 3.55 FW
Works on 3.15, 3.50 FW.
FW <= 2.03-? - WebCore::ImageInputType::attach Heap UaF (CVE-2013-2857)
- Chromium bugs reporters
- Nintendo Wii U hackers for exploiting this vulnerability
- CelesteBlue for testing on PS4 FW 2.03
Use-after-free with input type image. Error event was fired synchronously blowing away the input element from underneath.
Yes in ? FW
- 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)
- 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) 
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.
- first POC for 1.76 PS4 by nas and Proxima
- live test
- PS4 playground 1.76 by CTurt
- PSVita 2.00-3.20 webkit exploit
Yes in 2.00 FW
- Working on 1.01-1.76 FW.
- Very old firmwares (<= 1.05) don't 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 userland 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 userland ASLR easily.
- Now we have to dump entire userland sandboxed memory, and by studying it we can defeat ASLR:
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 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.
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 userland memory then executing it.
- 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs).
JiT removed from webbrowser
- Workaround is to use ROP.
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 doesn't 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
FW <= 7.02 - IPV6_2292PKTOPTIONS UaF (yielding arbitrary kernel R/W)
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.
- TheFloW's PoC for FreeBSD 9 and 12
- PS4 6.72 WebKit + Kernel Exploit implementation by sleirsgoevy
- PS4 5.05-6.72 WebKit + Kernel Exploit implementation by ChendoChap
Yes in 7.50 FW
FW <= 5.07 - BPF Race Condition (Yielding Double Free())
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).
Yes in 5.50 FW
FW <= 4.55 - BPF Race Condition (Yielding UaF)
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).
Yes in 4.70 FW
FW <= 6.00 ?6.02? - sys_getcontext Information Leak (kASLR defeat)
- coming soon by CelesteBlue
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().
- QuickHEN by CelesteBlue (v2 not released yet)
- KitHEN by CelesteBlue (not released yet)
Yes somewhere between 6.00 and 6.20 FW
FW <= 4.07 - sys_thr_get_ucontext Information Leak (kASLR defeat)
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().
Yes in 4.50 FW
FW <= 4.05 - NamedObj Type Confusion (Yielding UaF)
- Chaitlin Tech for having been the first to show they had pwned PS4 FW 4.01 at Geekpwn convention. (2016-10-24)
- fail0verflow for the first writeup (2017-10-19)
- Specter for rewriting the exploit using a different object, and releasing it publicly (2017-12-27)
- fail0verflow's writeup on the 1.01-4.05 namedobj kernel exploit (2017-10-19)
- Specter's first writeup (2017-10-20)
- Specter's writeup on his 4.05 implementation (2017-12-28)
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).
Yes in 4.06 FW
Works on FWs 4.00-4.05. On <=3.70 FW we haven't found a way to leak the target object, but it might be doable as F0F did it on 1.01.
FW <= 1.76 - dlclose Kernel Heap Overflow
- Discovered by CTurt. Privately implemented thanks to qwertyoruiop. CTurt published a writeup then the exploit was publicly implemented by kR105 and on another side by Zer0xFF and Bigboss (psxdev).
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).
Yes in 2.00 FW
FW <= 1.76 - BadIRET
- Ported from FreeBSD 9 to PS4 by CTurt.
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 userland memory, providing an attacker with a method of privilege escalation.
Yes in 2.00 FW
- 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.
- In 5.0x FW and above, "Supervisor Mode Access Prevention" (SMAP), a new custom mitigation was added to the kernel to prevent exploiters from pivoting the kernel stack pointer into userland memory (attempting to do so would crash the system).
- A new exploitation strategy is needed to run kernel ROP chains, such as qwertyoruiop method used in the 5.05 BPF kernel exploit:
We need to get our ROP chain into kernel memory. To do this, qwertyoruiop decided to go with the method he used on the iPhone 7 - essentially using JOP to push a bunch of stack frames onto the kernel stack, and memcpy()'ing the chain into RSP.