1623888 - (CVE-2020-12408) URL spoof: RTL character in URL flips domain and path if domain contains no directional characters (e.g. ip address)

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Anonymous]

Attachment: URL Spoofing.png

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

1. Post the following link in the status bar: 127.0.0.1/ا/http://attack.com

Actual results:

You would notice that the URL has been flipped from Right to left and the status bar dispays http://attack.com/‭ا/127.0.0.1 while it displays the content from the IP address.

Expected results:

Ip address should be shown first.

Comment 1

[:Gijs (he/him)]

I could have sworn we've got this on file but I cannot find it. Marco?

Comment 2

[Marco Bonardo [:mak]]

Notice we de-emphasize everything that is not the real host and we try to keep the host visible, so the problem is quite limited.

I don't think this is much different from bug 1395854 and bug 525831. I'd probably dupe to the former or add as a see also.

Comment 3

[Drew Willcoxon :adw]

I agree this doesn't seem different from bug 1395854.

Comment 4

[Anonymous]

Can you cc me on the respective bug please?

Comment 5

[Anonymous]

Hi, the bug you're refering to is about mixing latin with arabic TLD - therefore thats sec- low

In this bug it doesn't work with latin language. It works only with the IP Address. Simply placing these characters such as U+0600, U+7000, u+8000 etc in "Filepath" followed by the URL you wish to spoof such as Google.com, the URL provided in file path is shifted towards host name making it moderate risked bug.

For eg:

http://182.176.65.7/%D8%A7/http:/google.com

Comment 6

[Anonymous]

Attachment: Suggestion.jpg

If you'd notice - it shows correct order of the URL in the suggestions. Can't you implement same behavior on omnibox?

Comment 7

[Anonymous]

http://182.176.65.7/%EF%B9%B0https:/mail.google.com/mail - One more example. It totally controls the omnibox.

Comment 8

[Marco Bonardo [:mak]]

(In reply to Anonymous from comment #5)

Hi, the bug you're refering to is about mixing latin with arabic TLD - therefore thats sec- low

it's not much different, because the real origin stays visible and the non real origin is de-emphasized. The security risk is pretty much the same.

Comment 9

[Anonymous]

Attachment: Example 2.jpg

Hi, I meant to say this is different bug than Issue 1395854 because if you'd try to re-create the URL similar to as with the comment # 7 with the arabic TLD ( Isue 1395854 ) you cannot spoof it but with this bug you can. You can pratically control the omni box with this bug.

Comment 10

[Marco Bonardo [:mak]]

I'm ok with keeping both bugs open due to the differences in STR, but I don't think the risk is higher here, it's already possible to "spoof" a fake origin with RTL origins. How is your example worse spoofing than this https://bug1395854.bmoattachments.org/attachment.cgi?id=8903485&t=gqeQ0WpNrA2RGXW6lPOV3C from bug 1395854?

One point in favor of fixing this sooner, is that Chrome seems to handle it better than us, so let's keep this as parity-chrome

Anyway, we must go through the security team for audit.

Comment 11

[Anonymous]

C#10
By placing neutral characters such as "/", "ا" in filepath causes the URL to be flipped and displayed from Right To Left. However, in order for the URL to be spoofed in bug 1395854, the URL must contain arabic TLD which is quite revealing. and less decieving to users.

Comment 12

[Jonathan Kew [:jfkthame]]

FWIW, I notice that this only "works" for http, which means the browser will show the crossed-out padlock indicating an insecure connection.

If we try to do the same thing for an https connection, the presence of "https" at the beginning of the address bar ensures LTR direction for the numeric address: https://127.0.0.1/ا/https://attack.com

Comment 13

[Anonymous]

This is caused by the fact that the digits and dots in the IP address are "weak" left-to-right characters, which means the rightmost "strong" character is U+0627 ARABIC LETTER ALEF, giving the whole string a right-to-left context and flipping the host and path parts of the URL.

Comment 14

[Marco Bonardo [:mak]]

That is also valid for IPV6, we should likely force a direction when we're trimming.

Comment 15

[Marco Bonardo [:mak]]

I think this is a regression of bug 1322542

Comment 16

[Marco Bonardo [:mak]]

Attachment: Bug 1623888. r=gijs!,itiel!

Comment 17

[Marco Bonardo [:mak]]

Comment on attachment 9135034 [details]
Bug 1623888. r=gijs!,itiel!

Security Approval Request

• How easily could an exploit be constructed based on the patch?: There's one in this report, should be easy
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Unknown
• Which older supported branches are affected by this flaw?: beta, release
• If not all supported branches, which bug introduced the flaw?: Bug 1322542
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Probably the patch applies unchanged
• How likely is this patch to cause regressions; how much testing does it need?: Automated testing is not trivial for this visual case, QA can easily check various mixups of LTR/RTL domain/path.

Comment 18

[Daniel Veditz [:dveditz]]

Took me a while to figure out why I couldn't reproduce it: I turn off browser.urlbar.trimURLs and the presence of the real http:// scheme tells us which way to present the URL.

The spec says URLs should (must? I'll have to look) be presented in a LTR context even when they contain RTL elements. In my case the "http" prefix does that. Maybe we need to make sure we always put a LTR marker (\u200E) in front when we strip the scheme (a RTL scheme would be invalid since schemes must be ASCII).

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 9135034 [details]
Bug 1623888. r=gijs!,itiel!

This is sec-low so you don't need sec-approval to land. Sorry for the delay setting it.

Comment 20

[Anonymous]

Hi, I reported the same bug in chromium - They marked this as High Risked bug and $3000 as a bounty.

Comment 21

[:Gijs (he/him)]

(In reply to Anonymous from comment #20)

Hi, I reported the same bug in chromium - They marked this as High Risked bug and $3000 as a bounty.

Can you link to the chromium issue?

Comment 22

[Anonymous]

https://bugs.chromium.org/p/chromium/issues/detail?id=709417

Comment 23

[Marco Bonardo [:mak]]

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

Maybe we need to make sure we always put a LTR marker (\u200E) in front when we strip the scheme (a RTL scheme would be invalid since schemes must be ASCII).

On a second thought, it's a lot more complicate and risky than expected, because adding a char breaks all of the code assumption we make about selection indices. It would very likely introduce many subtle bugs and maintenance costs, we used to have textValue and value in the past for the urlbar, and it was a lot of added complication, while today value is the same as the input field value. I think we should retain this simplification for now and keep enforcing LTR through css.

Comment 24

[:Gijs (he/him)]

Ehsan, Itiel tagged you on phab ( https://phabricator.services.mozilla.com/D67817#2069096 ) but you won't have been able to see it because this is a sec bug. Pinging you here to make up for that. :-)

Comment 25

[Anonymous]

Can you update the Sec- to high just like chrome?

Comment 26

[Jonathan Kew [:jfkthame]]

Not sure what Marco thinks, but personally I'm not sure this is really a high-security issue. The fact that it can't be applied to an https:// connection (and non-https connections show an explicit non-secure indicator in the address bar) would seem to make it hard to exploit convincingly.

Comment 27

[Marco Bonardo [:mak]]

It's not my duty, we have a security team for that, Daniel is part of it and their decision is what matters in the end.
My dev opinion is this is a sec-low: info panel, http and domain hilight are present to guide the user.
Note that Chrome strips https, and their report is on Android, where there's no info panel.

Comment 28

[Julien Cristau [:jcristau]]

sec-low, not new in 75, and we're in rc week, so I think we should leave this for 76.

Comment 29

[Anonymous]

See also: https://bugs.chromium.org/p/chromium/issues/detail?id=624213

Comment 30

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Landed:
https://hg.mozilla.org/integration/autoland/rev/8748e324ef4404ea43b11716e933a3a32a736a63

Backed out:

https://hg.mozilla.org/integration/autoland/rev/2330b35ff8c62308f72dc060f93976639b6f2297

Push with failure:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedJob=296551754&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=8748e324ef4404ea43b11716e933a3a32a736a63
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=296676557&repo=autoland

[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Check the textoverflow attribute - "" == "" -
[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - Testing http://اسماء.شبكة/%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20/test/
[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Selection sanity check - 0 == 0 -
[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | URL Bar should be focused - {} == {} -
[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Check the scheme value - "" == "" -
[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Check the scheme box visibility - "hidden" == "hidden" -
[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - Buffered messages finished
[task 2020-04-07T20:35:13.418Z] 20:35:13 INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Uncaught exception - undefined - timed out after 50 tries.

Comment 31

[Anonymous]

Attachment: URL spoofing.jpg

I've created one more spoofed URL using the invisible Character “⠀” (U+2800) (which could be another bug i.e convert the invisible characters into code) , therefore, increasing the attacking risk of URL spoofing.

Hence, RTL+ space, formatting, invisible characters can lead to URL Spoofing -

http://127.0.0.1/%D8%A7/https://attack.com%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80%E2%A0%80

Comment 33

[Anonymous]

Attachment: Google.com/fakepath Spoofing

I've reproduce the example given in comment 31 using google.com/fakepath - because not decoding invisible characters could be a separate bug, therefore, reported it.

Comment 34

[Marco Bonardo [:mak]]

Attachment: Bug 1623888. r=gijs!,itiel!

Comment 35

[Marco Bonardo [:mak]]

Attachment: Bug 1623888 - Tests. r=gijs

Depends on D71549

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Given that we're out of Betas this cycle and this is sec-low, I think we can let this fix ride Fx77 when it's ready.

Comment 37

[Anonymous]

See Also: Bug 1633225

Comment 38

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/0803e4025eb5787139b348a3d66d3b6e36b63833
https://hg.mozilla.org/mozilla-central/rev/0803e4025eb5

Comment 39

[Raluca Popovici, Desktop QA]

I verified this bug in Firefox 77.0b1 and Nightly 78.0a1 (2020-05-05) and is fixed. I will update the flags accordingly.

Comment 40

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 41

[Daniel Veditz [:dveditz]]

Combined bug bounty awarded for this bug for the underlying "use path to spoof" mechanism, and bug 1629506 and bug 1633225 for spoofy characters that can be used for the actual spoofing.

Comment 42

[Marco Bonardo [:mak]]

This landed in 77 and we are 4 weeks after the release of it, thus I'm planning to land the test.

Comment 43

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/3f3cfe0d800b81d5f1424e5e6dd84680680f03d8
https://hg.mozilla.org/mozilla-central/rev/3f3cfe0d800b