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 296: Line 296:
----
----


=== FW 6.00-9.60 - FrameLoader::loadInSameDocument() UaF (CVE-2022-22620) leading to arbitrary RW ===
=== FW 6.00-9.60 - FrameLoader::loadInSameDocument UaF (CVE-2022-22620) leading to arbitrary RW ===


==== Credits ====
==== Credits ====
Line 312: Line 312:


==== 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) {
    alert('you get a crash after you close this alert');
    event.state; // use the freed SerializedScriptValue
    alert('WebKit version not vulnerable');
}


addEventListener('popstate', pop);
By default, arguments to functions should be reference-counted. Raw pointers should only be used in rare exceptions.


history.pushState('state1', '', location + '#foo'); // URL with a hash
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('state2', '');


setTimeout(() => {
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.
    input.focus();
    input.onblur = () => {
        history.replaceState('state3', '')
    };
    setTimeout(() => {
        history.back(); // trigger loadInSameDocument()
    }, 1000);
}, 1000);


</source>
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.
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>.
 
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.


==== Exploit Implementation ====
==== Exploit Implementation ====
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)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps4/Vulnerabilities"