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

firefox: Add patch to fix AES GCM IV bit size #87708

Merged
merged 1 commit into from May 13, 2020

Conversation

@aszlig
Copy link
Member

aszlig commented May 13, 2020

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 favour of the header file definition.

Since the test I've used 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, 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 in preparation for the 76 release, but subsequently got reverted 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 and also by testing manually using Jitsi Meet and Nextcloud Talk.

@aszlig aszlig requested review from andir and edolstra May 13, 2020
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 <aszlig@nix.build>
@aszlig aszlig force-pushed the aszlig:firefox-nss-3.52-fix branch from c9ca9a4 to 8fb4997 May 13, 2020
@andir andir self-assigned this May 13, 2020
@andir andir merged commit 8ba41a1 into NixOS:master May 13, 2020
14 checks passed
14 checks passed
Evaluation Performance Report Evaluator Performance Report
Details
grahamcofborg-eval ^.^!
Details
grahamcofborg-eval-check-maintainers matching changed paths to changed attrs...
Details
grahamcofborg-eval-check-meta config.nix: checkMeta = true
Details
grahamcofborg-eval-darwin nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="8fb4997"; rev="8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c"; } ./pkgs/t
Details
grahamcofborg-eval-lib-tests nix-build --arg pkgs import ./. {} ./lib/tests/release.nix
Details
grahamcofborg-eval-nixos nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="8fb4997"; rev="8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c"; } ./nixos/
Details
grahamcofborg-eval-nixos-manual nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="8fb4997"; rev="8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c"; } ./nixos/
Details
grahamcofborg-eval-nixos-options nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="8fb4997"; rev="8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c"; } ./nixos/
Details
grahamcofborg-eval-nixpkgs-manual nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="8fb4997"; rev="8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c"; } ./pkgs/t
Details
grahamcofborg-eval-nixpkgs-tarball nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="8fb4997"; rev="8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c"; } ./pkgs/t
Details
grahamcofborg-eval-nixpkgs-unstable-jobset nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev="8fb4997"; rev="8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c"; } ./pkgs/t
Details
grahamcofborg-eval-package-list nix-env -qa --json --file .
Details
grahamcofborg-eval-package-list-no-aliases nix-env -qa --json --file . --arg config { allowAliases = false; }
Details
@andir
Copy link
Member

andir commented May 13, 2020

Thank you very much! I noticed something was off yesterday but haven't had a chance to look into it yet. This change did indeed fix it. I'll work on backporting it next.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.