Editing Vulnerabilities

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

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 173: 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 191: 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 230: Line 230:
== Usermode Exploits (WebKit) ==
== Usermode Exploits (WebKit) ==


=== WebKit sources ===
=== FW 6.00-9.60 - FrameLoader::loadInSameDocument UaF (CVE-2022-22620) leading to arbitrary RW ===
[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 ====
==== 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 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)
* Anonymous for making an OOM PoC for webkit-gtk, PS4 and PS5 (2023-10-03) then making an arbitrary RW PoC for webkit-gtk, PS4 7.00-9.60 and PS5 1.00-5.10 (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 ====
==== Analysis ====
Line 249: 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 <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 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 <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.
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 <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.
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. Here's a Proof-of-Concept that will crash:
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">
input = document.body.appendChild(document.createElement('input'));
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().


foo = document.body.appendChild(document.createElement('a'));
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.
foo.id = 'foo';


function pop(event) {
By default, arguments to functions should be reference-counted. Raw pointers should only be used in rare exceptions.
    alert('you get a crash after you close this alert');
    event.state; // use the freed SerializedScriptValue
    alert('WebKit version not vulnerable');
}


addEventListener('popstate', pop);
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.
 
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>.
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.


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.
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 ====
Line 294: Line 273:
* [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 and PS5 by anonymous on ps4-dev discord (to mirror)]
* [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)]
* [https://discord.com Arbitrary RW PoC for PS4 7.00-9.60 and PS5 1.00-5.10 by anonymous on ps4-dev discord (to mirror)]


==== Patched ====
==== Patched ====
'''Yes''' on PS4 FW 10.00 and PS5 FW 6.00.
'''Yes''' on PS4 FW 10.00 and '''Probably''' on 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.
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.
Tested working on PS4 FWs 6.00-9.60 and PS5 FWs 1.00-5.10. 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 584: 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 748: Line 727:
* 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 libkernel.sprx by libSceWebkit2.sprx
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.
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 ===
=== DEP / NX ===
Line 764: Line 738:
=== 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.
* Workaround is to use ROP.
* Workaround is to use ROP.


Line 788: Line 761:


* 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
=== 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 ==
== Kernel Exploits ==
Line 1,103: Line 1,072:


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


Please note that all contributions to PS4 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS4 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)