1858570 - (CVE-2023-6209) inconsistent parsing of relative URLs starting with "///something" with a path-traversal "/../" part

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[Rachmat Abdul Rokhim]

Attachment: p0c.html

Mozilla Firefox will ask for confirmation when accessing a url that does not require authentication using the basic auth scheme. By crafting a payload on the href property in the html link attackers can bypass the process of confirmation.

Step to reproduce :

1. Install web server
2. Create html file and save it to your web server path (example of html file is attached)
3. Open html file

Live demo : http://206.189.194.11/p0c.html
Poc video : https://drive.google.com/file/d/1NXP2MEikvXx0YLybfewHhe16FAXRmbal/view?usp=sharing

Comment 1

[Daniel Veditz [:dveditz]]

The confirmations of our anti-phishing feature are a red-herring. The problem is we are mis-parsing relative URLs. Or maybe Chrome and Safari are? But at least they agree. In a a two-slash relative URL, we know the first part is a hostname, so we don't let any processing of path traversal segments ("/../") affect what we know is the host name. href="//mozilla.org/../evil.com" goes to https://mozilla.org/evil.com

When an href starts with three slashes we maybe treat it as an empty host, and then let the path collapsing erase the first term. But then when we actually put it all together with the scheme we do treat the term after 3 slashes as the host. href="///mozilla.org/../evil.com" goes to https://evil.com

Testcase:

var base = "https://example.com";

console.log("3-slash relative is the same as 2-slash: ",
  (new URL("///mozilla.org/evil.com",base)).href == (new URL("//mozilla.org/evil.com",base)).href );

console.log("3-slash relative  with path traversal is the same as 2-slash: ",
  (new URL("///mozilla.org/../evil.com",base)).href == (new URL("//mozilla.org/../evil.com",base)).href );

In Chrome and Safari both are true. In Firefox the first is true and the second is false.

This isn't exactly a security bug in Firefox itself, but this difference with other browsers could contribute to Firefox-user-only website vulnerabilities. I think this should fit nicely with the 2023 URL interop effort. Would it be easier to incorporate into the testsuite if this were not a hidden bug?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

Right, this is something where Firefox diverges from the spec
https://jsdom.github.io/whatwg-url/#url=Ly8vbW96aWxsYS5vcmcvLi4vZXZpbC5jb20=&base=aHR0cDovL2V4YW1wbGUuY29t

We should definitely fix it.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1858570 - Fix relative URL path starting with multiple slashes r=#necko

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1858570 - Add WPT for scheme relative URLs starting with multiple slashes r=#necko

Depends on D190784

Comment 5

[Rachmat Abdul Rokhim]

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

The confirmations of our anti-phishing feature are a red-herring. The problem is we are mis-parsing relative URLs. Or maybe Chrome and Safari are? But at least they agree. In a a two-slash relative URL, we know the first part is a hostname, so we don't let any processing of path traversal segments ("/../") affect what we know is the host name. href="//mozilla.org/../evil.com" goes to https://mozilla.org/evil.com

When an href starts with three slashes we maybe treat it as an empty host, and then let the path collapsing erase the first term. But then when we actually put it all together with the scheme we do treat the term after 3 slashes as the host. href="///mozilla.org/../evil.com" goes to https://evil.com

Testcase:

var base = "https://example.com";

console.log("3-slash relative is the same as 2-slash: ",
  (new URL("///mozilla.org/evil.com",base)).href == (new URL("//mozilla.org/evil.com",base)).href );

console.log("3-slash relative  with path traversal is the same as 2-slash: ",
  (new URL("///mozilla.org/../evil.com",base)).href == (new URL("//mozilla.org/../evil.com",base)).href );

In Chrome and Safari both are true. In Firefox the first is true and the second is false.

This isn't exactly a security bug in Firefox itself, but this difference with other browsers could contribute to Firefox-user-only website vulnerabilities. I think this should fit nicely with the 2023 URL interop effort. Would it be easier to incorporate into the testsuite if this were not a hidden bug?

Thank you for awesome explanation

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1015d0599d51
Fix relative URL path starting with multiple slashes r=necko-reviewers,kershaw

Comment 7

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

https://hg.mozilla.org/mozilla-central/rev/1015d0599d51

Comment 8

[Rachmat Abdul Rokhim]

It's good to know that the bug I reported has been resolved. I would like to know, does the bug I reported qualify for a bounty?

Comment 9

[Daniel Veditz [:dveditz]]

Congratulations: we are awarding a bug bounty for this bug.

Comment 10

[Rachmat Abdul Rokhim]

Thank you ! 😁

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR115 approval when you get a chance.

Comment 12

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 9358032 [details]
Bug 1858570 - Fix relative URL path starting with multiple slashes r=#necko

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Possible incorrect parsing of scheme relative URLs
• User impact if declined: As noted in comment 1, Firefox might incorrectly replace the hostname of the parsed URL with a path segment
• Fix Landed on Version: 120
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This change makes it so that we skip multiple slashes after :// when coalescing the directory of the path so that we do not inadvertently change the hostname.

Comment 13

[Hani Yacoub, Desktop QA]

Verified as fixed on Firefox 121.0a1 (2023-11-06) and Firefox 120.0b6 on macOS 11.6, Windows 10 x64 and on Ubuntu 20.04.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9358032 [details]
Bug 1858570 - Fix relative URL path starting with multiple slashes r=#necko

Approved for 115.5esr.

Comment 15

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/ec15c0924e39

Comment 16

[Hani Yacoub, Desktop QA]

Verified as fixed on Firefox 1115.5.0esr (treeherder build) on macOS 11.6, Windows 10 x64 and on Ubuntu 20.04.

Comment 17

[Daniel Veditz [:dveditz]]

Attachment: advisory.txt

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/023a5c518562
Add WPT for scheme relative URLs starting with multiple slashes r=necko-reviewers,kershaw

Comment 19

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

https://hg.mozilla.org/mozilla-central/rev/023a5c518562

Comment 20

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter