Closed Bug 1623888 (CVE-2020-12408) Opened 6 months ago Closed 5 months ago

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

Categories

(Firefox :: Address Bar, defect, P2)

74 Branch
defect
Points:
3

Tracking

()

VERIFIED FIXED
Firefox 77
Iteration:
77.2 - Apr 20 - May 3
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- wontfix
firefox75 + wontfix
firefox76 + wontfix
firefox77 + verified
firefox78 --- verified

People

(Reporter: rayyanh12, Assigned: mak)

References

(Regressed 1 open bug, Regression)

Details

(4 keywords, Whiteboard: [post-critsmash-triage][adv-main77+])

Attachments

(8 files, 1 obsolete file)

Attached image 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.

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

Component: Untriaged → Address Bar
Flags: needinfo?(mak)
Summary: RTL character in URL flips domain and path ( URL Spoofing ) → URL spoof: RTL character in URL flips domain and path if domain contains no directional characters (e.g. ip address)

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.

Flags: needinfo?(mak)

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

Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1395854

Can you cc me on the respective bug please?

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

Attached image Suggestion.jpg

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

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

(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.

Attached image 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.

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.

Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(dveditz)
Keywords: parity-chrome
Resolution: DUPLICATE → ---
Priority: -- → P2
See Also: → 1395854

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.

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

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.

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

Assignee: nobody → mak
Status: REOPENED → ASSIGNED

I think this is a regression of bug 1322542

Keywords: regression
Regressed by: 1322542
Attached file Bug 1623888. r=gijs!,itiel! (obsolete) —

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.
Attachment #9135034 - Flags: sec-approval?
Flags: needinfo?(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).

Keywords: sec-low

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.

Attachment #9135034 - Flags: sec-approval? → sec-approval+

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

(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?

Flags: needinfo?(rayyanh12)
Flags: needinfo?(rayyanh12)

(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.

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. :-)

Flags: needinfo?(ehsan)

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

Flags: needinfo?(mak)

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.

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.

Flags: needinfo?(mak)

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

Attachment #9135034 - Attachment description: Bug 1623888. r=gijs → Bug 1623888. r=gijs!,itiel!

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.

Flags: needinfo?(mak)
Attached image 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

Duplicate of this bug: 1629438

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.

See Also: → 1629506
Flags: needinfo?(mak)
Iteration: --- → 77.1 - Apr 6 - Apr 19
Iteration: 77.1 - Apr 6 - Apr 19 → 77.2 - Apr 20 - May 3
Attachment #9135034 - Attachment is obsolete: true
Flags: needinfo?(itiel_yn8)

Depends on D71549

Flags: needinfo?(itiel_yn8)

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.

See Also: Bug 1633225

See Also: → 1633225
See Also: 1633225
See Also: 1629506
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 6 months ago5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 77
Regressions: 1633885
Flags: sec-bounty?
Keywords: csectype-spoof
Points: --- → 3
Flags: qe-verify+
Whiteboard: [post-critsmash-triage]

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

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressions: 1635947
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main77-]
Whiteboard: [post-critsmash-triage][adv-main77-] → [post-critsmash-triage][adv-main77+]
Attached file advisory.txt
Alias: CVE-2020-12408

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.

Flags: sec-bounty? → sec-bounty+
Flags: in-testsuite?

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

Flags: needinfo?(ehsan)
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.