Closed Bug 1858570 (CVE-2023-6209) Opened 10 months ago Closed 9 months ago

inconsistent parsing of relative URLs starting with "///something" with a path-traversal "/../" part

Categories

(Core :: Networking, defect, P2)

defect

Tracking

()

VERIFIED FIXED
120 Branch
Tracking Status
firefox-esr115 120+ verified
firefox119 --- wontfix
firefox120 + verified
firefox121 --- verified

People

(Reporter: rachmat.abdul.ro, Assigned: valentin)

References

Details

(Keywords: reporter-external, sec-moderate, Whiteboard: [adv-main120+][adv-esr115.5+][reporter-external] [client-bounty-form] [verif?][necko-triaged][necko-priority-queue])

Attachments

(4 files)

Attached file 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

Flags: sec-bounty?

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?

Group: firefox-core-security → core-security
Status: UNCONFIRMED → NEW
Component: Security → Networking
Ever confirmed: true
Keywords: sec-moderate
Product: Firefox → Core
Summary: bypass redirect confirmation with basic auth url scheme with HTML links → inconsistent parsing of relative URLs starting with "///something" with a path-traversal "/../" part
Group: core-security → network-core-security
Assignee: nobody → valentin.gosu
Severity: -- → S3
Priority: -- → P2
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][necko-triaged][necko-priority-queue]

(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

Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/1015d0599d51
Fix relative URL path starting with multiple slashes r=necko-reviewers,kershaw
Group: network-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 120 Branch

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?

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

Flags: sec-bounty? → sec-bounty+

Thank you ! 😁

Flags: qe-verify+
QA Whiteboard: [post-critsmash-triage]

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

Flags: needinfo?(valentin.gosu)

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.
Flags: needinfo?(moz.valentin)
Attachment #9358032 - Flags: approval-mozilla-esr115?
QA Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][qa-triaged]

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.

Attachment #9358033 - Flags: approval-mozilla-esr115?

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

Approved for 115.5esr.

Attachment #9358032 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+

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

Status: RESOLVED → VERIFIED
QA Whiteboard: [post-critsmash-triage][qa-triaged] → [post-critsmash-triage]
Flags: qe-verify+
Whiteboard: [reporter-external] [client-bounty-form] [verif?][necko-triaged][necko-priority-queue] → [adv-main120+][adv-esr115.5+][reporter-external] [client-bounty-form] [verif?][necko-triaged][necko-priority-queue]
Attached file advisory.txt
Alias: CVE-2023-6209
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/023a5c518562
Add WPT for scheme relative URLs starting with multiple slashes r=necko-reviewers,kershaw

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

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: