Closed Bug 1754738 Opened 2 years ago Closed 2 years ago

Consider not building WebDriver components for release versions of Firefox

Categories

(Remote Protocol :: WebDriver BiDi, defect)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mark, Unassigned)

References

Details

Following the notification of CVE-2022-22757 I investigated what WebDriver BiDi actually does, what it's used for, and how similar sec bugs could be a big problem for end users.
I've also seen that bug 1753997 plans to enable it on release channels.

I think this is a mistake. IMHO this would create an unacceptably large attack surface for complete remote control of users' web browsers. End users would realistically have zero use of this capability; it belongs in debug builds only and should not even be built on release channels, let alone enabled!

Please consider not building remote access&control interfaces to Firefox on builds shipped out to users. This could literally become a backdoor to full control of a user's browser (and in effect, system) if exploited either through a discovered bug or external malware that makes it onto the user's system and enables/uses the WebDriver plumbing in Firefox.

Hello Mark. Thank you for filing this bug and bringing up your concerns about enabling the WebDriver BiDi protocol on release builds of Firefox. In the following I'll give more details about our implementation; hopefully this will address your concerns.

First about the use case: WebDriver BiDi is intended to allow authors to test web applications against Firefox. This means that it doesn't make sense to ship only in debug builds; experience suggests that such a feature must be in release channel builds before web authors will rely on it in their test and CI systems.

WebDriver BiDi is not the first remote protocol in Firefox. There is Marionette, which backs our WebDriver HTTP implementation, and has been available in release builds for many years. There is also the DevTools remote debugging capability, which allows clients (like VSCode) to control the browser. Similar features exist in all popular web browsers today, including Chrome, Edge and Safari.

That means that WebDriver BiDi is not adding new capabilities beyond what was already possible. Of course we still have to be sure that the feature can't be misused. Implementation wise, we have several safeguards to prevent abuse:

  1. To enable each of these protocols a specific command line argument has to be passed when starting Firefox. When that's not done the appropriate components won't be enabled at all. That makes it very difficult to accidentally enable these protocols, and an attacker would need full remote code execution to enable the features in Firefox. In that case they can already take full control of the machine.

  2. When any of the remote debugging protocols are enabled via the command line argument we display an orange striped location bar including a robot icon (attachment 9218672 [details]). This is highly visible to users and should warn them if the protocol is enabled unintentionally.

  3. Even when WebDriver-BiDi is enabled, the default configuration only allows WebSockets clients on the same machine to connect. Any connection containing an Origin header, which includes any connection originating from a web browser, will be rejected, as will any connection with an incorrect Host header.

Given the above safety measures, we are confident that enabling WebDriver-BiDi does not put Firefox users at risk.

That means that I'm going to close this bug as wontfix, but don't hesitate to ask if you have any remaining concerns. Thanks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX

Thanks for your explanation, however I'm not at all as confident as you are that this is perfectly safe.

  1. The WebDriver HTTP implementation you referred to even mentions in its preamble that it "may also be used in such a way as to allow in-browser scripts to control a — possibly separate — browser". So the possibility is there for WebDriver HTTP to be used by in-browser scripts.
  2. As stated, any bug in the implementation or external malware could allow the browser to be a fully capable and controllable backdoor - especially considering in the normal case, the browser's chrome runs with full privileges. Malware may, for example, start the browser with the necessary command-line parameters to be run in "development mode" -- especially if it's possible to run the browser headless. Similarly, there is no prevention of such malware to change the default configuration to allow full access, negating point 3. By design, such configurations would be malleable to allow automated testing setups.
  3. With how Firefox also allows remote configuration setups, some of the measures in place here could also be thwarted on endpoints by a non-local attacker that has compromised the (local/corporate) network, which is a real concern in this era of a lot of remote/VPN work. The potential for disastrous breaches is staggering.
  4. An extra concern is that WebDriver BiDi is, as the name suggests, a bi-directional protocol. This would allow for real-time streaming control and response of the browser in question.

My concern isn't with a direct practical exploit (in that case I wouldn't have filed an open bug) but rather with the (apparently on-going) efforts to have debugging and development interfaces in release versions of Firefox that are shipped out to millions of users of whom only an insignificantly small number would actually have use of these interfaces and remote protocols. IMHO it goes right against best security practices and, as said, offers an unacceptably large attack surface, even if there are a few safeguards in place that prevent casual exploitation.

Whatever happened to Firefox developer editions? Those would be prime, release-grade builds to have this kind of extra tooling available. Why not offer specific builds to users who have need of automation tools and strip those out of broad-audience releases for the common user? In such a version you would be able to cater to the specific use-case of authors to test web applications against Firefox in an automated fashion. For their use, there would be no practical difference to their workflow if the builds are otherwise release builds (as I do understand debug builds are a poor representation of the final product and do not offer anything useful to them). So a similar distinction you make between debug and release builds would be to make a distinction between release-dev builds and release-user builds, if you get my meaning.

I mean, from a security perspective it's pretty much a no-brainer that you do not want remote access and control interfaces built into pivotal and mission-critical pieces of client software that see no use in normal operation for all those clients. Marionette, devtools remote debugging and WebDriver simply do not belong in release-grade software.

I hope you're willing to consider these points in your next sec/dev meeting and discuss my concerns.

Hi Mark,

I think we agree that this isn't perfectly safe. However, the remote debugging protocols require a command line argument to be enabled.
If you have malware on your computer, you have a more severe problem than anyone changing how Firefox is started by default.
However, even if malware would do this and enable remote debugging, then the address bar will be orange and the site identity panel will show a robot icon instead of a lock or a crossed-out lock.
This leaves us to implementation bugs that allow someone to remotely enable remote debugging. I find it very unlikely, given how remote debugging needs to be enabled (it needs a command line flag). We currently know of no such bugs, though we solicit and receive various security bugs that fall into this or similar severity through our bug bounty program.

Now, regarding your comments about general best practices: I agree that there are millions of users who might not need the remote debugging capability. What you and I call "normal" operation might, however, be wildly different for everyone out there. At the same time, it's also true that there are hundreds of developers who create and test their website exclusively for browsers other than Firefox, leaving our users with a broken and unsupported experience.. It is in our long-term interest to make it easy for developers to test Firefox release - the same browser that the aforementioned million users have. It would be only cumbersome and detrimental to our efforts if we required folks to download some arcane testing build of Firefox.

I admit that this is a trade-off and that you might make a different one. I also fully understand that some people choose different risk profiles. As I understand it, you're using a forked, self-compiled version of Firefox and I believe Henrik will be able to give you a pointer where you can flip a compile-time define to disable this functionality. Which will hopefully satisfy your risk profile.

However let me repeat: We invite everyone to identify and report flaws and will happily pay a significant bounty for people who manage to remote-control a default Firefox installation that does not have the command line flag set.

(In reply to Frederik Braun [:freddy] from comment #3)

[..] I believe Henrik will be able to give you a pointer where you can flip a compile-time define to disable this functionality. Which will hopefully satisfy your risk profile.

Yes, I'm happy to do so. For all the mentioned remote debugging protocols (not devtools) a single build flag exists and can easily be toggled if needed for specific builds of Firefox. It' even documented and can be found at:

https://firefox-source-docs.mozilla.org/remote/Building.html#full-build-mode

ac_add_options --disable-webdriver

Once set no code related to the Remote Agent and Marionette will be packaged.

It is in our long-term interest to make it easy for developers to test Firefox release - the same browser that the aforementioned million users have.

I fully understand where you're coming from; I don't necessarily agree with you letting every user sit on a ticking time bomb in favor of making sure that "websites can test (release) Firefox in an automated way". There's an obvious elephant in the room here, though:
Why don't you leverage your extension APIs to make this possible? That way only those that need this functionality will have it when they install the extensions to suit their needs for testing -- and others won't have this inherent risk of an always-built and one switch/bug/configuration-mistake away from being enabled remote control tool to contend with.

Aside from that, I still think you're restricting your view on the potential for abuse here. As much as you want me to take into account the wildly different interpretations of "normal" operations, you're at the same time not willing to take into account the wildly different interpretations of a "default Firefox installation" which will be just as varied by definition. Try to look at this from a big picture perspective, not just "virgin OS with a newly installed clean Firefox on a new profile with no external configuration for the endpoint" as the scope boundaries for considering "flaws".

As I understand it, you're using a forked, self-compiled version of Firefox and I believe Henrik will be able to give you a pointer where you can flip a compile-time define to disable this functionality. Which will hopefully satisfy your risk profile.

You don't understand my situation. I do not use a "self-compiled version of Firefox". I don't use Firefox at all. Any mozconfig build flag to disable webdriver will not apply to my use case.
This bug was also not filed because of some self-serving perception that would directly affect my independent browser. It was filed because the basic idea of having full remote control features built into a web browser by default is a massive red flag for anyone who has some idea about networking/computing security, and needed to be brought up. This is to make your browser safer to use for your users.
Maybe I shouldn't have bothered trying to do the right thing... :/

Indeed, I misunderstood your situation and the motivation for filing this bug.
However, it's still not "full remote control by default", as you say. Indeed if it were, it would be massive red flag. But it's not.

(In reply to Frederik Braun [:freddy] from comment #6)

Indeed, I misunderstood your situation and the motivation for filing this bug.
However, it's still not "full remote control by default", as you say. Indeed if it were, it would be massive red flag. But it's not.

I never said that it was, merely that it could be. Please don't twist my words.
The risk of it is a massive red flag. If there was a direct exploitable vulnerability I would have found then that would have been way more than just a red flag, and once again, in that case I would not have filed an open bug but would have used responsible disclosure instead.

You need to log in before you can comment on or make changes to this bug.