1619930 - Vulnerable python packages listed as used in the build system

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[:Gijs (he/him)]

Someone in matrix flagged up that the versions of urllib3, pyyaml and requests on the esr68 branch all have reported security vulnerabilities out against them. It doesn't look like these versions have changed on m-c. In fact, it doesn't look like https://searchfox.org/mozilla-central/source/python/safety/Pipfile.lock#114 has changed at all since it landed; I'm not sure if we actually end up using these packages. Assuming that we only fetch content we control and parse yaml files we control, using parameters we control, we're probably fine. Simon, can you comment on my reading of this / what next steps should be?

Still, better safe than sorry, so filing as a sec bug.

Comment 1

[Simon Fraser [:sfraser] ⌚️GMT]

I don't know if the use of mach python-safety ever took off: it would replicate the features that GitHub are notifying us about. If no-one is using it and we have alternatives then perhaps we should just remove it. Otherwise, I could update the requirements. It's only ever looking at our own in-tree source.

Sample output:

Unexpected Results
------------------
/Users/sfraser/hg.m.o/mozilla-central/testing/mozbase/mozproxy/mozproxy/backends/mitm/mitmproxy_requirements.txt
  FAIL pyopenssl - pyopenssl installed:16.2.0 affected:<17.5.0 description:Python Cryptographic Authority pyopenssl version prior to version 17.5.0 contains a CWE-416: Use After Free vulnerability in X509 object handling that can result in Use after free can lead to possible denial of service or remote code execution.. This attack appear to be exploitable via Depends on the calling application and if it retains a reference to the memory.. This vulnerability appears to have been fixed in 17.5.0.
  FAIL pyopenssl - pyopenssl installed:16.2.0 affected:<17.5.0 description:Python Cryptographic Authority pyopenssl version Before 17.5.0 contains a CWE - 401 : Failure to Release Memory Before Removing Last Reference vulnerability in PKCS #12 Store that can result in Denial of service if memory runs low or is exhausted.
  FAIL requests - requests installed:2.13.0 affected:<=2.19.1 description:The Requests package before 2.19.1 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
  FAIL /Users/sfraser/hg.m.o/mozilla-central/testing/mozbase/mozproxy/mozproxy/backends/mitm/mitmproxy_requirements.txt - requests pyopenssl
/Users/sfraser/hg.m.o/mozilla-central/testing/mozharness/requirements.txt
  FAIL pycrypto - pycrypto installed:2.6.1 affected:<=2.6.1 description:Heap-based buffer overflow in the ALGnew function in block_templace.c in Python Cryptography Toolkit (aka pycrypto) 2.6.1 allows remote attackers to execute arbitrary code as demonstrated by a crafted iv parameter to cryptmsg.py.
  FAIL urllib3 - urllib3 installed:1.9.1 affected:<1.23 description:urllib3 before 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
  FAIL /Users/sfraser/hg.m.o/mozilla-central/testing/mozharness/requirements.txt - pycrypto urllib3
/Users/sfraser/hg.m.o/mozilla-central/third_party/python/mozilla-version/requirements-coveralls.txt
  FAIL requests - requests installed:2.19.1 affected:<=2.19.1 description:The Requests package before 2.19.1 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
  FAIL /Users/sfraser/hg.m.o/mozilla-central/third_party/python/mozilla-version/requirements-coveralls.txt - requests
/Users/sfraser/hg.m.o/mozilla-central/third_party/python/mozilla-version/requirements-docs.txt
  FAIL requests - requests installed:2.19.1 affected:<=2.19.1 description:The Requests package before 2.19.1 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
  FAIL /Users/sfraser/hg.m.o/mozilla-central/third_party/python/mozilla-version/requirements-docs.txt - requests
/Users/sfraser/hg.m.o/mozilla-central/third_party/python/requirements.txt
  FAIL requests - requests installed:2.9.1 affected:<=2.19.1 description:The Requests package before 2.19.1 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
  FAIL /Users/sfraser/hg.m.o/mozilla-central/third_party/python/requirements.txt - requests
/Users/sfraser/hg.m.o/mozilla-central/toolkit/components/telemetry/tests/marionette/harness/requirements.txt
  FAIL requests - requests installed:2.11.1 affected:<=2.19.1 description:The Requests package before 2.19.1 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
  FAIL /Users/sfraser/hg.m.o/mozilla-central/toolkit/components/telemetry/tests/marionette/harness/requirements.txt - requests

Comment 2

[Simon Fraser [:sfraser] ⌚️GMT]

Attachment: Bug 1619930 Update python-safety dependencies r?gijs

Comment 3

[Simon Fraser [:sfraser] ⌚️GMT]

The patch to update Pipfile is a stopgap, and we should either just remove python-safety or encourage its use.

Comment 4

[Daniel Veditz [:dveditz]]

Since these are python and we don't ship python the bugs don't directly impact Firefox users. Does "Building Firefox" expose the libraries to enough attacker-controlled content (from people who can check in? anyone else?) to trigger the bugs, presumably attacking the machines building firefox?

Comment 5

[Simon Fraser [:sfraser] ⌚️GMT]

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

Since these are python and we don't ship python the bugs don't directly impact Firefox users. Does "Building Firefox" expose the libraries to enough attacker-controlled content (from people who can check in? anyone else?) to trigger the bugs, presumably attacking the machines building firefox?

This code isn't run in the CI systems at all. People would run mach python-safety locally, and pipenv would install things in a local virtualenv, and scan a local clone of the repo. Anything that reaches our infrastructure goes through try and code review as normal.

Comment 6

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

https://hg.mozilla.org/integration/autoland/rev/ddfb7aaf4223f0e225aabde9644f671989eac7a3
https://hg.mozilla.org/mozilla-central/rev/ddfb7aaf4223

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Doesn't sound like this is something we need to worry about backporting, but LMK if that's incorrect.

Comment 8

[Simon Fraser [:sfraser] ⌚️GMT]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #7)

Doesn't sound like this is something we need to worry about backporting, but LMK if that's incorrect.

Agreed, we should let it ride the trains