1892289 - Add a '-data' command line argument as a flag that it's safe to open a data: URL and isn't passed in as a default browser URL.

Status: UNCONFIRMED

(Toolkit :: Startup and Profile System, enhancement)

Description

[Andrii Ivasenko]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

Steps to reproduce:

I'm trying to run following command from console of Linux Ubuntu : firefox "data:text/html;charset=utf8;base64,PGh0bWw+PGJvZHk+PHA+IFRoaXMgaXMgYSB0ZXN0PC9wPjwvYm9keT48L2h0bWw+" or from MacOSX 14.4.1 open -a "Firefox" "data:text/html;charset=utf8;base64,PGh0bWw+PGJvZHk+PHA+IFRoaXMgaXMgYSB0ZXN0PC9wPjwvYm9keT48L2h0bWw+"

Actual results:

Firefox window appears with data: url in address bar, but it's not executed - one should click the address bar content with mouse and press enter, then data: url is executed and "This is test" is displayed in the page.

Expected results:

data: url should execute immediately and "This is test" should appear in the page.
I'm aware that data: url top level navigation was disabled and due to the https://blog.mozilla.org/security/2017/11/27/blocking-top-level-navigations-data-urls-firefox-59/ it can only be executed if user types it in address bar. But trying to launch it from command line with explisit data: url argument should be treated as direct user input. Chrome, Edge and Opera are running data: urls from command line without any problems and we rely on this mechanism in our product.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ray Kraesig [:rkraesig]]

The launcher process is Windows-only and is not relevant to Linux or macOS. I'm not sure what the right category is, though — given that

Firefox window appears with data: url in address bar

it's probably not anything at the command-line parsing level. Moving to Firefox :: General for rebucketing.

Comment 3

[Emily McMinn :emcminn]

Hey Christoph, is this working as intended here? Should we consider following the other browsers in our behaviour?

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Emily McMinn :emcminn from comment #3)

Hey Christoph, is this working as intended here? Should we consider following the other browsers in our behaviour?

Freddy, Gijs, back when we implemented the top-level data: URI blocker I remember we considered the use case described in this bug and we explicitly decided that data: URI command line arguments in the form of firefox data:foo should be blocked.

Generally I think Firefox' behaviour is solid, though given that other browsers handle command line arguments differently should we re-consider that part? What's your take?

Comment 5

[:Gijs (he/him)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #4)

(In reply to Emily McMinn :emcminn from comment #3)

Hey Christoph, is this working as intended here? Should we consider following the other browsers in our behaviour?

Freddy, Gijs, back when we implemented the top-level data: URI blocker I remember we considered the use case described in this bug and we explicitly decided that data: URI command line arguments in the form of firefox data:foo should be blocked.

I don't recall this conversation - that could be my memory and the fact that it was 7 years ago, or perhaps I was not included in that conversation at the time? Bug 1331351 comment 24 suggests that dveditz suggested how to do this - but it's not clear if that is also when/where we decided to treat external URLs differently, or if that happened earlier.

I note that I don't see anything in the browser console explaining why this is blocked, nor is there a user-facing error page. That doesn't seem ideal if we decide to retain the existing behaviour.

Generally I think Firefox' behaviour is solid, though given that other browsers handle command line arguments differently should we re-consider that part? What's your take?

Well, from a security perspective I'm not quite sure I see what the threat model is where blocking this is super useful. In most scenarios where an attacker could launch Firefox with an arbitrary commandline argument, they could provide a file or https URL with the potentially harmful content anyway, presumably?

Assuming we load data URIs loaded like this with the null principal if/when we load them (which appears to be the case), and we load them in a content process (which appears to be the case - though it's not a web isolated process, presumably because we don't have an origin to isolate it by?), ISTM the risk is pretty minimal.

The exception for providing a file or https URL would be cases where either the machine is restricted in some way from accessing https URLs (e.g. enterprise locked down scenarios) or file URLs in some situations (snap/flatpak builds might run into this on Linux?), or where an attacker is not on the local machine at all but is using firefox: schemes (for which we recently removed support again, and which prior to that we'd limited nested URI support to http and https) to specifically invoke Firefox with an attacker-provided URL.

I'm not convinced that those scenarios are worth having a specific block for data URIs? But maybe I underestimate how common they are or how serious a compromise would be.

The flip side is that I also do not fully understand why an external product in 2024 would rely on data URIs.

Reporter, would you mind elaborating on your product's "mechanism" and why it needs data URIs?

Comment 6

[Andrii Ivasenko]

Hi Team,
Our client uses integrated browser control on different platforms, but it also supports opening web content/services using external browser of choice on each platform. Some of our web services historically require some specific data set along with url either in http request via headers or transferred via POST request (GET is not supported). Since http request headers with external browser is not an option we use intermediate html with POST self submitting form and feeding it to the external browser via data: url command parameter in order to avoid creating some temporary html files in local file system and all the handling coupled with this.

Comment 7

[Christoph Kerschbaumer [:ckerschb]]

(In reply to :Gijs (he/him) from comment #5)

Freddy, Gijs, back when we implemented the top-level data: URI blocker I remember we considered the use case described in this bug and we explicitly decided that data: URI command line arguments in the form of firefox data:foo should be blocked.

I don't recall this conversation - that could be my memory and the fact that it was 7 years ago, or perhaps I was not included in that conversation at the time? Bug 1331351 comment 24 suggests that dveditz suggested how to do this - but it's not clear if that is also when/where we decided to treat external URLs differently, or if that happened earlier.

I can't recall exactly who was in those conversation. My point was more that we explicitly added a variable named aLoadFromExternal and also the comment we added, see https://bugzilla.mozilla.org/attachment.cgi?id=8888269&action=diff. I suppose we can't easily distinguish between loads coming from the command line and loads coming from Thunderbird. I remember we wanted to block the loads from Thunderbird. However, if we can easily distinguish those loads, then I am OK with opening up the blocking mechanism and allow loads from the commandline.

Comment 8

[:Gijs (he/him)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #7)

I can't recall exactly who was in those conversation. My point was more that we explicitly added a variable named aLoadFromExternal and also the comment we added, see https://bugzilla.mozilla.org/attachment.cgi?id=8888269&action=diff. I suppose we can't easily distinguish between loads coming from the command line and loads coming from Thunderbird. I remember we wanted to block the loads from Thunderbird. However, if we can easily distinguish those loads, then I am OK with opening up the blocking mechanism and allow loads from the commandline.

Unless I'm mistaken, I doubt we register Firefox as a handler for the data protocol in the OS, so I don't think TB would hand us those URLs unless it had specific code to (manually) look up and/or then invoke Firefox with custom arguments. It wouldn't happen through "normal" external protocol handling via the OS. So if this is about the vector of "you receive a malicious email with a data: link, we shouldn't execute it in Firefox when clicked", I think that shouldn't create a vulnerability in any browser today, not because we block at the commandline but because the OS would not pass on such a URI.

It'd be worth checking my intuition is correct there before doing anything... but in that case, it sounds like we could open this up?

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

You are right, I verified that opening the data: URI form my mail client does not work. However, I am still not convinced we are not missing anything. Dan, you were part of the discussion back then, do you remember why we added aLoadFromExternal (see patch: https://bugzilla.mozilla.org/attachment.cgi?id=8888269&action=diff) back when we implemented the data: URI blocker?

Or put differently, is there any risk that we can't see right now why we should not allow data: URIs to opened using the commandline a la firefox data:...?

If not, then I think we can open it up, though we would need to find someone who can work on it.

Comment 10

[Daniel Veditz [:dveditz]]

Well, from a security perspective I'm not quite sure I see what the threat model is where blocking this is super useful. In most scenarios where an attacker could launch Firefox with an arbitrary commandline argument, they could provide a file or https URL with the potentially harmful content anyway, presumably?

The problem with data: urls is largely because they were used in spoofing attacks, not because the content itself is any more dangerous than any other web page. We do NOT block data urls in an iframe (where user's can't see the URL) which shows this isn't a security concern about the content. Those same spoofing attacks can be conducted from other communication apps like mail and chat so we do want to block them from there.

The command-line itself is not dangerous, except that we can't always tell when the link has come from a command line in a shell or from another app via the OS "default browser" handling. We do have an extra argument on Windows that lets us know, but we don't have an equivalent on Mac or Linux. Could we add another argument, like -data that the OS handler won't use and that we could interpret as "Yes, I am intentionally using a data url"?

Comment 11

[:Gijs (he/him)]

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

Could we add another argument, like -data that the OS handler won't use and that we could interpret as "Yes, I am intentionally using a data url"?

I would take a patch that did this.