Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upgrade-2020-05-27-2efedf8fc74 #341

Open
wants to merge 337 commits into
base: nixos-19.09
Choose a base branch
from

Conversation

nixos-auto-pr[bot]
Copy link

@nixos-auto-pr nixos-auto-pr bot commented May 26, 2020

Pull request automatique

Avancement mise à jour

  • Fusionner la branche

NeQuissimus and others added 30 commits March 12, 2020 05:58
(cherry picked from commit 281bd03)
(cherry picked from commit 243cd9f)
(cherry picked from commit 8330317)
(cherry picked from commit 773462c)
(cherry picked from commit 41d8bb1)
(Older version finished on Hydra.)
(Older version finished on Hydra.)
https://www.samba.org/samba/history/security.html
Tested: $ nix build -f nixos/release.nix tests.samba.x86_64-linux
Contains only the version update from 8be61f7,
the module-changes are not needed on 19.09 since the database is always
configured properly here.
x86_64-linux rebuilds have finished, so let's merge
to get the security fixes early.
(cherry picked from commit 291c735)
/cc roundup NixOS#79725
includes fix for nC-SA-2020-015.

See nextcloud/server#19976, the SA currently
has a typo - adressed in
nextcloud/security-advisories#21.
The substitition in smtpd/parse.y isn't necessary anymore.
The hardcoded /usr/libexec/ has been replaced by a PATH_LIBEXEC #define,
which will be set properly by the build system.

(cherry picked from commit 9658850)
(cherry picked from commit 77da495)
Release notes aren't available at this time [1] it is likely to be
related to a recent mail to oss-security (either [2] or [3]).

[1] https://www.mail-archive.com/[email protected]/msg04888.html
[2] https://www.openwall.com/lists/oss-security/2020/02/24/5
[3] https://www.openwall.com/lists/oss-security/2020/02/24/4

(cherry picked from commit 09725e5)
flokli and others added 30 commits April 28, 2020 19:08
While it's already possible to invoke `update-data` with the `--rev`
argument, one still needs to run all later phases manually.

Fix this, by having `update-all` also accept a `--rev` argument, and
pass it down to `update-data`.

Also, make the help text a bit more usable, by suggesting the usual
versioning scheme used these times.

(cherry picked from commit 191c2c6)
(cherry picked from commit f7ddd30)
(cherry picked from commit c86c77b)
`bundix -l` doesn't work, as it treats bundler's warning about upgrading
the lockfile version as an error, so invoke `bundle lock` manually.

(cherry picked from commit 4c26ab4)
Fixes: CVE-2020-6061, CVE-2020-6062

An exploitable heap overflow vulnerability exists in the way CoTURN
4.5.1.1 web server parses POST requests. A specially crafted HTTP
POST request can lead to information leaks and other misbehavior.
An attacker needs to send an HTTPS request to trigger this vulnerability.

An exploitable denial-of-service vulnerability exists in the way
CoTURN 4.5.1.1 web server parses POST requests. A specially crafted
HTTP POST request can lead to server crash and denial of service.
An attacker needs to send an HTTP request to trigger this vulnerability.

(cherry picked from commit 704a018)
…l-19.09

monotone: openssl in botan is not needed, so drop to avoid old openssl
https://github.com/roundcube/roundcubemail/releases/tag/1.3.11

This contains some important security fixes, hence the package-bump.
[19.09] chromium: 81.0.4044.122 -> 81.0.4044.129 (backport)
(cherry picked from commit 9eb6dc7)
(cherry picked from commit fdd0d0d)
[19.09] salt: 2019.2.0 -> 2019.2.4
(cherry picked from commit 324e40f)
(cherry picked from commit 3911336)
chromium: 81.0.4044.129 -> 81.0.4044.138
According to https://monerodocs.org/interacting/monerod-reference/#node-rpc-api
the correct option is restricted-rpc, not restrict-rpc.

(cherry picked from commit e7ab236)
Regression introduced by bce5268.

The bit size of the initialisation vector for AES GCM has been
introduced in NSS version 3.52 in the CK_GCM_PARMS struct via the
ulIvBits field.

Unfortunately, Firefox 68.8.0 and 76.0 do not set this field and thus it
gets initialised to zero, which in turn causes IV generation to fail.

I found out about this because WebRTC stopped working after updating to
NSS 3.52 and so I started bisecting.

Since there wasn't an obvious error in Firefox hinting towards NSS but
instead just the video stream ended up as a "null" stream, I didn't
suspect the NSS update to be the culprit at first. So I verified a few
times and then also started bisecting the actual commit in NSS that
caused the issue.

This turned out to be the problematic change:

https://phabricator.services.mozilla.com/D63241

> One notable change was caused by an inconsistancy between the spec and
> the released headers in PKCS#11 v2.40. CK_GCM_PARAMS had an extra
> field in the header that was not in the spec. OASIS considers the
> header file to be normative, so PKCS#11 v3.0 resolved the issue in
> favor of the header file definition.

Since the test I've used[1] was a bit flaky, I still didn't believe the
result of the bisect to be accurate, but after running the test several
times leading same results I dug through the above change line by line
to get more clues.

It fortunately didn't take that long to stumble upon the ulIvBits change
(which is actually documented in the NSS 3.52 release notes[4], but I
managed to blatantly ignore it for some reason) and started checking the
Firefox source tree for changes regarding that field.

Initialisation of that new field has been introduced[2] in preparation
for the 76 release, but subsequently got reverted[3] prior to the
release, because Firefox 76 is expected to be shipped with NSS 3.51,
which didn't have the ulIvBits field.

The patch I'm adding here is just a reintroduction of that change,
because we're using NSS 3.52. Not initialising that field will break
WebRTC and WebCrypto, which I think the former seems to gain in
popularity these days ;-)

Tested the change against the mentioned VM test[1] and also by testing
manually using Jitsi Meet and Nextcloud Talk.

[1]: https://github.com/aszlig/avonc/tree/884315838b6f0ebb32b/tests/talk
[2]: https://hg.mozilla.org/mozilla-central/rev/3ed30e6b6de1
[3]: https://hg.mozilla.org/mozilla-central/rev/665137da70ee
[4]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.52_release_notes

Signed-off-by: aszlig <[email protected]>
(cherry picked from commit 8fb4997 & moved to packages.nix)
(cherry picked from commit b70435e)
[19.09] firefox: Add patch to fix AES GCM IV bit size
Since M81 won't receive any updates anymore and there are known
vulnerabilities we should mark it as insecure so that users are aware of
the risks.
Updating Chromium to M83 is unfortunately too challenging for
19.09, but as of today we've already covered the one month period of
security updates for "oldstable" and both 20.03 and nixos-unstable
contain recent versions (i.e. users should either update to the current
stable release or install Chromium from a different channel).

nixos-unstable PR for M83: NixOS#88206
[19.09] chromium: Mark as insecure
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.