1875248 - (CVE-2024-4773) Url Bar Spoofing (to blank URL bar) when navigating to specific application/octet-stream endpoint

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Islam]

Attachment: first_site_source.html

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0

The problem as i understood, originates from behavioral miss-match in response parsing and html renderer components. The Top level(Get) navigation to a page which responses with 404 status code and 'application/octet-stream' Content-Type leads to this bug in concrete.
This was actually discovered by accident, while doing an Authorized Pentesting engagement of a client Web app.

Complexity: One-click navigation to attacker controlled site

Steps to Reproduce:
So the steps involve an attacker hosting two ends, one for initial navigation and one for bug triggering.
First site just redirects to another(second) after some time of initial navigation, the Second one gives a crafted response triggering the spoofing while the content is freezed.
In real life case, a target just follows the attacker site link and then the url bar turns spoofed(cleaned url bar with freezed attacker site content - which makes illusion of seeing it as default Mozilla page in target side).

For Direct PoC demonstration, i hosted public ends which do the exploitation chain fully.
Just navigating to following link: https://eoxvf4u5flv9ndl.m.pipedream.net shows the bug. Wait for few seconds to see the url bar spoofing happen.

Giving the first site's html source code for helping better investigation in the attachment.

The response of second site which triggers the bug:

HTTP/2 404 Not Found
Date: Thu, 18 Jan 2024 10:58:08 GMT
Content-Type: application/octet-stream; charset=utf-8
Content-Length: 14
X-Powered-By: Express
Access-Control-Allow-Origin: *

Page not found

Comment 1

[Islam]

Actually, as the html attachment displays inline, it would do the job(bug triggering) when it is located.

Comment 2

[:Gijs (he/him)]

Thanks for the report, I can reproduce.

This is pretty confusing - the DOM bits suggest that we've navigated to about:blank, but nothing new is rendered nor is anything downloaded. Nika, do you know what's going on here?

Comment 3

[:Gijs (he/him)]

This seems to at least not be a recent regression. :-(

Comment 4

[Nika Layzell [:nika] (ni? for response)]

I've spent a bit of time looking into this, but I'm going to leave the ni? for now because while I've figured out what's happening, I'm not sure what the best approach to take going forward is.

The buggy situation here is effectively that when loading, we decide to do a process switch to load the new page due to the previous document being eligible to enter the BFCache. When doing this, we continue painting the previous page (bug 1677324) until we've painted the newly loaded document, which never ends up happening. (You can notice that the page which is being shown with the blank URL bar is not properly hooked up if you resize the browser window, as the viewport won't properly resize with it).

The new process which we switch into then ends up being unable to render the response, and returns NS_ERROR_WONT_HANDLE_CONTENT (https://searchfox.org/mozilla-central/rev/9d88be0557a5bc39d3da288f9aff71414baa303e/uriloader/base/nsURILoader.cpp#435). This error doesn't have a corresponding error page, so no new content page finishes loading or is painted in the new process. Instead, the new content process only has the initial about:blank document loaded, presumably leading to a blank URL bar.

In general if we think that a content process is going to not render any content, we prevent process switching (https://searchfox.org/mozilla-central/rev/9d88be0557a5bc39d3da288f9aff71414baa303e/netwerk/ipc/DocumentLoadListener.cpp#2595). In this case, we fail to do this due to https://searchfox.org/mozilla-central/rev/9d88be0557a5bc39d3da288f9aff71414baa303e/uriloader/base/nsURILoader.cpp#449. This check is only run in the parent process, returning a NS_OK exit status (i.e. not preventing a process switch), while in the content process we exit earlier with NS_ERROR_WONT_HANDLE_CONTENT. Switching the order of these checks wouldn't improve the situation either, as we'd still process switch and then fail to target the request in the content process.

Before bug 1626362 comment 35, this check returned NS_ERROR_FILE_NOT_FOUND instead of NS_OK. Changing the code to return that status, and moving the check before the NS_ERROR_WONT_HANDLE_CONTENT return causes a load error to be displayed rather than the buggy spoofing situation shown here. This more closely matches the behaviour shown by other browsers, but I'll need to make sure it doesn't break html/semantics/text-level-semantics/the-a-element/a-download-click-404.html given the comment and reasoning behind the original change (the test seems to pass locally?).

In addition to this, though, I wonder a bit whether it would make sense for us to harden the logic a bit. It seems like perhaps getting an errorpageless error for the first document loaded in a process after a process switch should be handled in some way to make sure we don't end up in this limbo state - perhaps some kind of special fallback error page and telemetry?

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1875248 - Check for network error preventing ExternalHelperAppService before DONT_RETARGET, r=smaug!

This reverts the change from 30cde47f9364e5c7da78fd08fa8ab21737d22399,
and instead re-orders the NS_ERROR_FILE_NOT_FOUND check before
DONT_RETARGET.

Testing suggests that a-download-click-404.html behaviour isn't
impacted, and this improves the handling of this edge-case when doing
process switching.

Comment 6

[Islam]

Hi, can i learn why the severity is changed to sec-low?

Comment 7

[Islam]

Hi Daniel Veditz,
As the "sec-low" severity is added by you, i think i should request the clarification from you. Can you explain the the Low severity assignment reason?

Comment 8

[Daniel Veditz [:dveditz]]

Most spoofing bugs are sec-low. In this case you are not spoofing the source of the content—which would be more severe—but rather hiding that source. Confusing and not great, but not misleading a victim into thinking some other site (e.g. "facebook") was the source. Of course you could make the page look exactly like Facebook before pulling this trick and confuse some people. People fall for phishing sites where the domain is complete gibberish so that's not a high bar. In addition, the spoofed content in this bug is inert and not even as useful as a phishing page.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dcc3c75ded45
Check for network error preventing ExternalHelperAppService before DONT_RETARGET, r=smaug

Comment 10

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

https://hg.mozilla.org/mozilla-central/rev/dcc3c75ded45

Comment 11

[Frederik Braun [:freddy]]

We've decided we're not going to award a bounty for this bug. We still consider the severity low.

Comment 12

[Islam]

hi Frederik Braun,
can i get an explanation for the bounty decison?
And there will be a cve assigned for the bug right? Also it would be great to get the timeline for the Cve release.
Thanks.

Comment 13

[Frederik Braun [:freddy]]

Looks like this has been fixed for Firefox 126, which is due to release in May. We will assign a CVE when we are a bit closer to the release date

We generally do not pay a bounty for bugs considered "sec-low". Our documentation for the but bounty policies is at https://www.mozilla.org/en-US/security/client-bug-bounty/ and our general guidelines for security severity is at https://wiki.mozilla.org/Security_Severity_Ratings/Client.

Comment 14

[Daniel Bodea [:danibodea]]

• This issue was reproduced in Firefox Release v125.0.3: Loading the test page will allow the content to remain displayed and the URL will be removed from the URLbar.
• This issue was verified in Beta v126.0b9 and v126.0 (RC build2) and Nightly v127.0a1: Loading the test page will allow the content to remain displayed for a fow seconds but then the following error is displayed:
  "File not found
  Firefox can’t find the file at https://eozmqjleoohswtv.m.pipedream.net/.
  Check the file name for capitalization or other typing errors.
  Check to see if the file was moved, renamed or deleted."
  The URL will not be removed from the URLbar.

Windows 10, MacOS11 and Ubuntu 22 were tested. Closing report as verified.

Comment 15

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt