1704422 - (CVE-2021-4221) Address Bar Spoofing due to Arabic RTL characters

Status: RESOLVED FIXED

(Fenix :: Toolbar, defect)

Description

[Rohan Sharma]

Attachment: firefox-android-poc.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

STEP 1: Click on "run" in attached file ("firefox-desktop-PoC.html")
The address bar will point to "www.mozilla.org", however the actual content is being delivered by "اختبار.اختبار"

The URL is not handled properly. Arabic characters in the domain name are being rendered from Right to Left(RTL) direction rather than Left to Right(LTR).

Actual results:

http://www.mozilla.org/hello/1/index.html/رابتخا.رابتخا

Expected results:

http://اختبار.اختبار/www.mozilla.org/hello/1/index.html
The address bar should point to "اختبار.اختبار" instead of "www.mozilla.org"

Comment 1

[Rohan Sharma]

Attachment: firefox-android-poc.html

Comment 2

[Daniel Veditz [:dveditz]]

The reporter has submitted this for bounty consideration

Comment 3

[Rohan Sharma]

Hi, we have passed 60 days for this vulnerability report. Any updates?

Comment 4

[Amedyne Moya [:amoya]]

Adding this to the team's current sprint to work on. Also refer to: https://mozilla-hub.atlassian.net/browse/FNXV2-17223

Comment 5

[Petru-Mugurel Lingurar [:petru]]

Seems like this is happening because of us removing the http(s) protocol for URLs displayed in the url bar here.

There “http ://اختبار.اختبار/www.mozilla.org/1” would become "اختبار.اختبار/www.mozilla.org/1" as expected but by default the arabic characters need to be read from right to left so that string will actually be displayed as “www.mozilla.org/1/اختبار.اختبار“.

To enforce left to right we need to prepend the "\u200E” left-to-right mark to the string which I did in this PR.

The same solution should probably be used on desktop also which shows the same issue.

Comment 6

[Jonathan Kew [:jfkthame]]

Is this "display" version of the URL used strictly for display only, or is the modified version exposed to the user in the sense of being able to select&copy it, or otherwise interact with its contents? E.g. if the user does "select all", "copy" in the URL bar, will they get the original URL or the edited version?

Comment 7

[Petru-Mugurel Lingurar [:petru]]

That is indeed only used for display.
The problem arise because for display we remove the the protocols so end up beginning the displayed URL with arabic characters which are read (and as such will be displayed) from right to left.
But when interacting with the url we are using the full URL of the current page.

Comment 8

[Petru-Mugurel Lingurar [:petru]]

Attachment: OnlyForDisplay.mp4

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Petru-Mugurel Lingurar [:petru] from comment #7)

That is indeed only used for display.
The problem arise because for display we remove the the protocols so end up beginning the displayed URL with arabic characters which are read (and as such will be displayed) from right to left.
But when interacting with the url we are using the full URL of the current page.

Thanks, that sounds like the right thing to do.

Comment 10

[Petru-Mugurel Lingurar [:petru]]

Adding Lorand from QA to see the poc and verify the fix.

Comment 11

[Kevin Brosnan [Ex-Mozilla]]

Verified that this is fixed https://github.com/mozilla-mobile/android-components/issues/10598#issuecomment-884892669

Comment 12

[Rohan Sharma]

When would you process the CVE assignment?

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

NI for comment 12

Comment 14

[Tom Ritter [:tjr]]

This should have been marked fixed and had the appropriate tracking flags set at the time so we could process the CVE and include it in the advisory. I will assign a CVE and update the prior advisory - to confirm this was fixed in Firefox for Android 92?

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

Yes that looks correct.

Comment 16

[Tom Ritter [:tjr]]

Attachment: advisory.txt