1681975 - (CVE-2021-29992) Side-Channel Vulnerability in base64 PEM file decoding

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P3)

Description

[florian.2018]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Steps to reproduce:

Dear Mozilla Security Team,

we are researchers from the Institute for IT security at the University
of Lübeck, and are contacting you because of a side-channel security
vulnerability we found in your library.

We performed a systematic analysis of several cryptographic libraries
and investigated the base64 decoding functions for non-constant time
behavior. We showed that most libraries leak key information, which can
be exploited with high resolution cache measurements, e.g. through a
single-stepped cache attack in SGX. This information can be used to
reduce the security of RSA keys by about one level. We believe that
every function processing sensitive data should perform its computations
in constant-time, to ensure that no secret information leaks via any
side-channels.

The core problem is caused by the usage of lookup tables in presence of
microarchitectural structures like caches, which introduce non-constant
timing behavior for memory accesses. The amount of leaked information
depends on the distribution of the lookup table entries over cache
lines, which is influenced by the table's memory alignment. We found
that none of the analyzed libraries forces a 64 byte-alignment, and in
some cases the compiler used unfortunate placement, leading to a high
and exploitable leakage.

We describe the details in our paper. The paper as
well includes a section proposing a possible mitigation with a
constant-time lookup-table approach. We also reference the
implementation used in BoringSSL, which is the only library we found
implementing base64 decoding and encoding in constant time and without
using lookup tables.
Please contact us, so we can send you the paper via E-Mail!

Specifically for the base64 decoding implementation in NSS we found that
lib/util/nssb64d.c is affected.

We submitted our paper to the IEEE Symposium on Security & Privacy 2021,
where it will be under anonymous review until February. Please keep it
confidential in the meantime, as other libraries are also affected.

Please let us know if you have questions.

Kind regards,

Florian Sieck, Sebastian Berndt, Jan Wichelmann and Thomas Eisenbarth

Actual results:

Expected results:

Comment 1

[Daniel Veditz [:dveditz]]

Kevin: how serious is this in the context of Firefox? This sounds more like a local attack than one that could be detected from web content.

Comment 2

[Kevin Jacobs [:kjacobs]]

Thank you for the report! Would you mind emailing me a copy of your paper? (I emailed about this the other day, but maybe it didn't go through - you can also use the email attached to my Bugzilla account).

I'm not sure that Firefox has any use cases where this would leak sensitive data (that's not available via simpler means), but perhaps there are other non-Mozilla uses where it's of more concern. Regardless, it would be good to have this.

I imagine that one potential vector for this is via import of an (unencrypted) private key in PKCS8/PEM format, but if it's encrypted I would think it's no longer viable.

Comment 3

[florian.2018]

Hello Kevin,

sorry for replying so late. I did indeed miss the mail. Will send you the paper now to the mail address with which you originally contacted me.
We can then also discuss the implications!

Comment 4

[Kevin Jacobs [:kjacobs]]

Thanks for emailing the paper! I'm going to call this sec-low for now, primarily due to the very limited set of use cases where this is likely to be exploited (particularly for Mozilla products).

CC'ing Bob since this is likely more of a concern to RedHat. I'm happy to upgrade the severity if you see fit. Either way, this is something we should fix.

Comment 5

[florian.2018]

You are welcome! I think that, concerning Mozilla products like Firefox or Thunderbird, you are right. For other software which might use NSS this could be different.

Great, we appreciate that you are going to fix this issue!

We did want to create a CVE for this issue, especially since many libraries are involved and for many of them the issue is more severe and some already asked for a CVE (since they are not a CNA and cannot create one). However, the MITRE CVE creation form stated that if a product of a CNA (CVE Numbering Authority) is involved, we are to contact the CNA in question which shall then create the CVE. Could you create a CVE for this issue? And do you know whether it could be used for all the involved products / libraries?

Best

Florian

Comment 9

[John Schanck [:jschanck] (out of office Aug 11-18)]

Attachment: Bug 1681975 - Avoid using a lookup table in nssb64d r=bbeurdouche

Comment 10

[Daniel Veditz [:dveditz]]

Could you create a CVE for this issue?

Use CVE-2021-29992 for the NSS instance of this vulnerability.

And do you know whether it could be used for all the involved products / libraries?

No, it can't. We can only assign CVEs for vulnerabilities in Mozilla implementations (code). Applying this patch would not fix any other implementation, and apparently it's possible to implement this functionality without making this mistake (your reference to BoringSSL) so by MITRE's rules each implementation needs it's own CVE. Other products that are affected because they use NSS can share this CVE.

Sometimes MITRE will assign an meta-CVE for an issue when something, usually at a protocol level, affects multiple implementations. You will have to ask MITRE for that. When you ask tell them that the issue affects multiple implementations (list them, if you have space in the form), and therefore there is no one CNA who is authoritative for this.

Comment 11

[Benjamin Beurdouche [:beurdouche]]

I have noticed that https://arxiv.org/abs/2108.04600v1 has been published so I am landing the fix now.
Note that I would have appreciated a ping beforehand... : )

We can open the bug after the Firefox release that will contain the fix.
https://hg.mozilla.org/projects/nss/rev/d454db6ad1fbb6b864383932c5bb23d339a4c95d

Comment 12

[Robert Relyea]

Thanks Benjamin. NSS has multiple DER decoders, but I suspect this one is the one we use in softoken to crack PKCS 8 data. This is a bigger problem for applications using dbm, because the keys are stored in dbm as pkcs8 blobs, but in sql databases, the only risk is when you import a pkcs12 file into NSS, so it's a fairly low risk to Firefox, and still a low risk for even our server use of NSS.

The patch contains it's own constant time routines. We should reform it using our already existing constant time macros in secport.c (PORT_CT_*).
bob

Comment 13

[Robert Relyea]

Oh wait, it's a base64 decoder, not a der decoder.
You'll have to be using NSS in a very unsusual way to get it to compromise any keys. Basically you need to hand inport the unencrypted base64 pkcs8 data. NSS doesn't store or use base 64 data for CPS in any native way. Only if you are using openssl unencrypted PEM files through something line pk11pem or in our application would this cause any issues, So it's low impact for both firefox and an RHEL usage (NSS can import unecrypted keys, but makes it very difficult).

Anyway the patch is fine, though it would be better if it used the PORT_CT_ macros for consistency.
bob

Comment 14

[Benjamin Beurdouche [:beurdouche]]

Noted, thanks for the tip Bob.

Comment 15

[florian.2018]

Hello!

Thanks for creating the CVE and the additionally information you provided, @Daniel! We will list the CVE in our publication after the fix has been released.

@Benjamin, sorry for not informing you beforehand. We weren't sure whether it is still going to be fixed. Next time we will definitely do! :-) And thanks for fixing the issue in NSS, although the impact is not that high!
Can you already tell whether it will automatically be part of the next upcoming release?

Best regards on behalf of the team

Florian

Comment 16

[Benjamin Beurdouche [:beurdouche]]

Hi Florian, no worries : )
It will be part of NSS 3.70 that will be released on September 2nd and will immediately go to the Firefox 93 branch which will be in Beta on September 6th. The Firefox 93 release will be on October 5th.
Best, B.

Comment 17

[florian.2018]

Thanks!

Best,
Florian