Editing Vulnerabilities
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
== Hardware Exploits == | == Hardware Exploits == | ||
Line 163: | Line 94: | ||
==== 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 173: | Line 104: | ||
* 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 - | === FW <=10.71 - BD-JB2 - 0-day vulnerabilities by TheFloW === | ||
==== Credits ==== | ==== Credits ==== | ||
* TheFloW for | * TheFloW for finding these vulnerabilities (before 2023-09-11) | ||
==== Analysis ==== | ==== Analysis ==== | ||
* [https://twitter.com/theflow0/status/1701154155744645349 | * [https://twitter.com/theflow0/status/1701154155744645349 BD-JB2 logs on a 7.61 PS5 from TheFloW (2023-09-11] | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
Undisclosed. | |||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
Unreleased. | |||
==== Patched ==== | ==== Patched ==== | ||
'''No''' as of PS4 FW 10.71 | '''No''' as of PS4 FW 10.71 and PS5 FW 7.61. | ||
=== FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW === | === FW <=9.00 - BD-JB - Five vulnerabilities chained by TheFloW === | ||
==== Credits ==== | ==== Credits ==== | ||
Line 197: | Line 127: | ||
* TheFloW for finding these vulnerabilities (around 2021-10-24) and disclosing them publicly on hackerone and hardwear.io (2022-06-10) | * 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) | * Sleirsgoevy for writing the first public implementation (2022-06-16) | ||
==== Analysis ==== | ==== Analysis ==== | ||
* [https://hackerone.com/reports/1379975 Official vulnerability report by TheFloW (2022-06-10)] | * [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)] | * [https://github.com/TheOfficialFloW/Presentations/blob/master/2022-hardwear-io-bd-jb.pdf Slides presented at hardwear.io by TheFloW (2022-06-10)] | ||
Line 230: | Line 158: | ||
== Usermode Exploits (WebKit) == | == Usermode Exploits (WebKit) == | ||
=== FW 6.00-8.50-?.?? - FrameLoader::loadInSameDocument UaF (CVE-2022-22620) leading to arbitrary RW === | |||
=== FW 6.00- | |||
==== Credits ==== | ==== Credits ==== | ||
* 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) | ||
==== Analysis ==== | ==== Analysis ==== | ||
* [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.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)] | * [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 ==== | ==== Bug Description ==== | ||
The History API | The bug is related to the web browser History API and is triggered by history.back() with the target state whose URL contains a hash: | ||
history.pushState("state1", "", location + "#foo"); // URL with a hash | |||
... | |||
history.back(); // triggers loadInSameDocument() | |||
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(). | |||
==== Exploit Implementation ==== | |||
* PoC by Maddie Stone in Maddie Stone's writeups | |||
* | * [https://github.com/springsec/CVE-2022-22620/blob/main/CVE-2022-22620_infoleak_exploit.html PoC of information leak by springsec] | ||
* [https://github.com/springsec/CVE-2022-22620/blob/main/CVE-2022-22620_infoleak_exploit.html | |||
==== Patched ==== | ==== Patched ==== | ||
''' | '''Maybe''' on PS4 FW 9.60 and '''Maybe''' on PS5 FW 4.51. | ||
Tested working on PS4 FWs 6.00- | Tested working on PS4 FWs 6.00-8.50 and PS5 FWs none. Untested: every PS5 FWs. PS4 FWs <=5.56 seems invulnerable as the HTML input field stays blurred (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 === | === FW 9.00-9.04 - WebCore::CSSFontFaceSet vulnerabilities leading to arbitrary RW === | ||
Line 328: | Line 211: | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
Description in WebKit fix commit by Myles C. Maxfield: | Description in WebKit fix commit by Myles C. Maxfield: | ||
After r256659, asking for a failed CSSFontFace's families() returns nullopt. It's possible to add a failed font to a CSSFontFaceSet (of course). When we do that, we recognize the font is failed and | 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 don't update our internal data structures, because there's no need to - we can't do anything useful with a failed font. If you _then_ try to remove the font from the CSSFontFace, we don't call families(), but instead just pull out the raw m_families member, and look in our internal data structures for it, but we don't find it, because it was never added. | ||
Description in Maddie Stone's write-up: | 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 | 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 don't 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: | Description by sleirsgoevy: | ||
Line 365: | Line 249: | ||
==== Bug Description ==== | ==== 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. | * 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. | ||
Line 394: | Line 279: | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
WebKit: JSC: BytecodeGenerator::hoistSloppyModeFunctionIfNecessary | WebKit: JSC: BytecodeGenerator::hoistSloppyModeFunctionIfNecessary doesn't 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. | 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. | ||
Line 584: | Line 469: | ||
==== 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 598: | Line 483: | ||
==== Bug Description ==== | ==== Bug Description ==== | ||
When attempting to update a vector via sortCompactedVector() - data is written based on a pointer, though the pointer | 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. | ||
==== Exploit Implementation ==== | ==== Exploit Implementation ==== | ||
Line 741: | Line 626: | ||
=== Usermode ASLR === | === Usermode ASLR === | ||
* Very old firmwares (<= 1.05) | * 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 usermode ASLR on FWs >=1.70, we can use the module imports table to find other modules address once we know SceWebkit2 address. | * 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. | ||
Line 748: | Line 633: | ||
* Between 1.76 and 4.05, Sony did that to prevent webkit exploiters from defeating usermode ASLR easily. | * 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 === | ||
Line 764: | Line 644: | ||
=== 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. | ||
Line 783: | Line 662: | ||
=== 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 | * 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 === | === 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 | * Around 6.50-6.70, device access got blocked or removed. Now you can no longer access devices from webbrowser | ||
== Kernel Exploits == | == Kernel Exploits == | ||
Line 1,103: | Line 978: | ||
==== Tested ==== | ==== Tested ==== | ||
Works on FWs 4.00-4.05. On <= 3.70 FW we | 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. | ||
---- | ---- | ||