1681103 - (CVE-2021-23989) Firefox Lite Full Address Bar Spoofing w/ Secure Padlock by Open Copied Link on the Address Bar

Status: VERIFIED FIXED

(Emerging Markets Graveyard :: Security: Firefox Lite, defect)

Description

[Irvan Kurniawan [:sourc7]]

Attachment: testcase.html

It is possible to spoof Firefox Lite full address bar with secure padlock, by typing or pasting URL on website with empty response body (https://www.google.com/csi) or closed port (https://www.google.com:82) to the address bar.

While Firefox Lite loads the content, the target website URL stays on the address bar, so we can spoof current content using unbeforeunload event.

Browser tested:

Firefox Lite 2.5.2 (20647)
WebView version: 86.0.4240.198 (released on Nov 11th, 2020)

Steps to Reproduce:

1. Visit attached testcase.html
2. Tap "Copy URL"
3. Tap on the address bar
4. Tap "Open Copied Link"
5. Address bar show: https://www.google.com/csi?response_type=auth&client_id=...
6. Spoofed content show: Sign in to continue to Google Drive

Mitigation:

Currently I can't reproduce this on another WebView browser:

• FOSS Browser on Google Play
• Yandex Browser Lite

They do mitigate this spoof vulnerability by only displaying website on the address bar when it successfully loaded.

Comment 1

[Irvan Kurniawan [:sourc7]]

Attachment: Firefox Lite - Open Copied Link Spoof.mp4

Comment 2

[Daniel Veditz [:dveditz]]

"moderate" because of the user-interaction req'd (you can't navigate into this situation), but excellent spoof.

Comment 3

[Irvan Kurniawan [:sourc7]]

(In reply to Daniel Veditz [:dveditz] from comment #2)

"moderate" because of the user-interaction req'd (you can't navigate into this situation), but excellent spoof.

Thanks Daniel for the explanation I really appreciate it, yes it's a great spoof.

Surprisingly I discovered the perfect spoof, it is possible to spoof the full address bar with secure padlock just by visiting website (no user-interaction required). The PoC is exceptionally easy to exploit as it only require:

• HTML <base> element

<base href="https://accounts.google.com/signin/v2/identifier">

• JS code

setTimeout(function() {
    window.history.replaceState("", "", location.href)
}, 100)

When user visit the page, the address bar will show https://accounts.google.com/signin/v2/identifier with interactable spoofed content.

Comment 4

[Irvan Kurniawan [:sourc7]]

Attachment: perfectspoof.html

Steps to Reproduce:

1. Visit attached perfectspoof.html
2. Address bar show: https://accounts.google.com/signin/v2/identifier?hl=id&passive=true&continue=...
3. Spoofed content show: Sign in Use your Google Account

Comment 5

[Irvan Kurniawan [:sourc7]]

Attachment: Firefox Lite - Full Address Bar Spoof.mp4

Comment 6

[Irvan Kurniawan [:sourc7]]

After looking at the root cause from Github mozilla-tw/FirefoxLite, I think the perfectspoof.html should be reported as a separate bug, but I've mistakenly posted the detail on this bug. Is this ok :dveditz?

The root cause of perfectspoof.html at comment 3 is when JS execute window.history.replaceState("", "", location.href), the WebView onPageFinished is pointing to the base href https://accounts.google.com/signin/v2/identifier, surprisingly it pass the url to WebViewClient doUpdateVisitedHistory(WebView view, String url, boolean isReload)

On Firefox Lite it also update the address bar when doUpdateVisitedHistory is called by passing String url parameter to update the address bar. Because of that condition Firefox Lite updated the address bar to https://accounts.google.com/signin/v2/identifier.

We can view the code at app/src/webkit/java/org/mozilla/focus/webkit/FocusWebViewClient.java I confirmed by changing the code from viewClient.onURLChanged(url) to viewClient.onURLChanged(view.getUrl()) it solve the perfectspoof.html bug.

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 9194803 [details]
perfectspoof.html

Moved to bug 1684986

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to Irvan Kurniawan (:sourc7) from comment #6)

... I think the perfectspoof.html should be reported as a separate bug, but I've mistakenly posted the detail on this bug. Is this ok :dveditz?

You're right: it's a separate (and worse!) issue. Created bug 1684986 to cover the new issue. I've also tagged comment 3 and following "offtopic" to hide them (so they don't derail any discussions about the original problem in this bug) but no disrespect is intended. It's a very good discovery and report.

Comment 9

[Irvan Kurniawan [:sourc7]]

Thanks Daniel for the correction, firstly I think the bug has same underlying code, but after deep digging into mozilla-tw/FirefoxLite code it was a different issue.

Comment 10

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

This bug is verified.

I've been reading through the code but it is not immediately obvious where this should be fixed. Ivan, I'm curious if you have any ideas. We will investigate more tomorrow.

Comment 11

[Irvan Kurniawan [:sourc7]]

(In reply to Stefan Arentz | :st3fan | ⏰ EST | he/him from comment #10)

This bug is verified.

I've been reading through the code but it is not immediately obvious where this should be fixed. Ivan, I'm curious if you have any ideas. We will investigate more tomorrow.

Thanks Stefan, the bug is at BrowserFragment.kt at updateURL() call on following function:

the loadUrl code:

override fun loadUrl(
    url: String,
    openNewTab: Boolean,
    isFromExternal: Boolean,
    onViewReadyCallback: Runnable?
) {
    updateURL(url)

and onUrlChanged code:

 override fun onUrlChanged(session: Session, url: String?) {
            chromeViewModel.onFocusedUrlChanged(url)
            if (!isForegroundSession(session)) {
                return
            }
            updateURL(url)
            shoppingSearchPromptMessageViewModel.checkShoppingSearchPromptVisibility(url)
        }

After tap "Open Copied Link", the updateURL() is called earlier to set the address bar to copied link's URL. So when user supplied url with empty response body, the WebViewClient is not navigating (stay on current page), but the address bar already set on that URL.

In this case we can follow Firefox for Android behavior, when the tab on the website is active (not in the new tab page) after tapping "Fill in links from clipboard", the address bar is not updated, because Firefox doesn't or failed to navigate to that URL.

I'll take a look if we can refactor the code to follow Firefox for Android behavior.

Comment 12

[Irvan Kurniawan [:sourc7]]

Attachment: addressbarspoof.patch

Finally I able to refactor the code to follow Firefox for Android behavior, now it works like below:

When user entered URL on the address bar -> update the progress bar -> when page successfully loaded -> update the address bar.

Comment 13

[Irvan Kurniawan [:sourc7]]

Attachment: addressbarspoof.patch

It turns out after removing webViewClient.notifyCurrentURL(url) it no longer pass the URL to BrowserFragment.kt onUrlChanged function; therefore on this updated patch I remove the unused condition check.

Comment 14

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Irvan, thank you so much for going beyond just reporting this issue. I'm going to review your patch and schedule a new release soon after.

Comment 15

[Irvan Kurniawan [:sourc7]]

Attachment: addressbarspoof.patch

(In reply to Irvan Kurniawan (:sourc7) from comment #13)

Created attachment 9202017 [details] [diff] [review]
addressbarspoof.patch

It turns out after removing webViewClient.notifyCurrentURL(url) it no longer pass the URL to BrowserFragment.kt onUrlChanged function; therefore on this updated patch I remove the unused condition check.

Thanks Stefan, surprisingly on some websites the onUrlChanged still receive the spoof URL, so I reverted to the previous patch.

Now I firmly sure this one solves the spoof issue.

Comment 16

[Irvan Kurniawan [:sourc7]]

Attachment: titleupdatespoof.patch

However I found a way to bypass the patch, on Firefox Lite it also update the address bar from WebViewClient onReceivedTitle callback. By adding document.title="newtitle" on beforeunload the address bar will also set to spoof URL.

Hereby I attach the additional patch to address the issue, it removes updateURL on WebViewClient onReceivedTitle callback, I also refactor address bar update code sequence on WebViewClient onPageStarted so the address bar will be updated quickly (same as using onReceivedTitle hack workaround).

Comment 17

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Irvan, apologies for the silence. We plan to ship this fix very soon. I am working on getting the patches in shape to get it out asap.

Comment 18

[Andrei Bodea[:andrei]]

Verified as fixed on the latest FF Lite 2.6.1(20652) WebView 89.0.4389.90 (provided by Stefan) with Google Pixel 4 XL (Android 11) and Samsung Galaxy S7 (Android 7).
Note that following the steps from the description everything works as expected.

Comment 19

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

This is shipping today to 25%. We'll keep an eye on it and then go to 100% later this week.

Comment 20

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Since this shipped, I am marking this as ASSIGNED/RESOLVED. Will soon publish the CVE in the Github project.

Comment 21

[Irvan Kurniawan [:sourc7]]

(In reply to Stefan Arentz | :st3fan | ⏰ EST | he/him from comment #20)

Since this shipped, I am marking this as ASSIGNED/RESOLVED. Will soon publish the CVE in the Github project.

Thank you Stefan for the update, I also confirmed this has been fixed on Firefox Lite 2.6.1(20652) (on Play Store) with WebView version: 89.0.4389.105.