1366464 - NSS accepts a certificate whose signature algorithm identifiers in tbsCertificate.signature and in Certificate.signatureAlgorithm are different

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P3)

Description

[chenchu]

Attachment: test cases.rar

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36

Steps to reproduce:

The attached RAR file contains basicCA.pem and 1.pem.

Steps to reproduce:

VERSIONS:
		NSS Version: [3.27]
		Operating System: [Ubuntu v1604-LTS x64] 

	REPRODUCTION STEPS:
	  1. Open the terminal of Unbuntu and create a certificate database:
		 certutil -N -d ./
		 (Note: press Enter to skip inputing password)
	  2. Add a CA certificate to the new certificate database:
		 certutil -A -i basicCA.pem -n ca -t "CT,C,C" -d ./
		 (Note: basiceCa.pem is one of attachements)
	  3. Add a end entity certificate (EEC) to the the new certificate database:
		 certutil -A -i 1.pem -n 1 -t ",," -d ./
		 (Note: 1.pem is another one of attachements)
	  4. Verify the EEC:
		 certutil -V -n 1 -d ./ -u S





Actual results:

certutil: certificate is valid





Expected results:

As for the certificate "1.pem", its signature algorithm identifier (SAI) Sha256WithRSAEncryption in tbsCertificate.signature and SAI Sha1WithRSAEncryption  in Certificate.signatureAlgorithm are different. NSS only looks at Certificate.signatureAlgorithm.

Policy checks prohibiting weak signature will pass and such certificates are exploitable by hackers.

Hence, it should be rejected.

Comment 1

[chenchu]

@David Keeler Our comprehensive testing shows that Firefox rejects such a certificate but Mozilla NSS accepts it. It means the security bug was fixed in Firefox as mentioned in bug 1077864 but still exists in NSS.

Bye the way, what is the meaning of "(use needinfo?)" which is after "[:keeler]"?





@Daniel Veditz[:devditz] What is the meaning of "Flags:needinfo?"? By the way, what is the meaning of "[:devditz]"?


Does the OS-level certificate validation module on Ubuntu and Windows refer to Mozilla NSS or others? If others, what are the OS-level certificate validation modules on Ubuntu and Windows? Thank you!

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

"needinfo" is a way of getting a bugzilla user's attention without assuming they actually read every item of bugmail that arrives in their inbox (many people don't as they receive such a high volume). You can use it at the bottom of the page ("Need more information from...").

Some programs on Ubuntu use NSS, but others do not. Windows has its own TLS/certificate verification implementation that the OS uses. I imagine most applications on Windows simply use the OS implementation, but some may use NSS.

Comment 3

[J.C. Jones [:jcj] (he/him)]

Note: Franziskus (currently NI'd) will be back Monday; his country has this as a holiday weekend.

Comment 4

[chenchu]

@David Keeler Thank your for your answer!

Comment 5

[Franziskus Kiefer [:franziskus]]

This should be checked by mozpkix and not NSS. So this is not a Firefox issue (unless bug bug 1366464 wasn't resolved properly).
For the pkix verification engines in NSS. This is a MUST in the rfc (for obvious reasons) so we should probably fix it at some point.

Comment 6

[chenchu]

@Franziskus May I ask some questions? Isn't mozpkix a part of NSS? If so, what does the pkix verification engines in NSS refer to? What's the relation between mozpkix and NSS? Thank you very much!

Comment 7

[Franziskus Kiefer [:franziskus]]

> Isn't mozpkix a part of NSS?

Unfortunately it's not. It is part of the Firefox code.

> What's the relation between mozpkix and NSS?

NSS allows to plug-in pkix verification engines. mozpkix uses this on the Firefox side.

> what does the pkix verification engines in NSS refer to?

There are multiple pkix engines in NSS at the moment. Depending on your build you'll either get the code from certhigh or more likely libpkix. Both verification engines are limited in its functionality.

Comment 8

[chenchu]

@Franziskus Thank you for your answer!

Comment 9

[Daniel Veditz [:dveditz]]

Kai: does Red Hat need a fix for this in NSS?

Comment 10

[Kai Engert (:KaiE:)]

Does Thunderbird use mozilla::pkix or NSS for certificate validation, when processing S/MIME signatures?

I'm guessing it uses NSS.

The attached example is validating a certificate for the "Email signer" usage, so it's probably relevant for Thunderbird.

Comment 11

[Kai Engert (:KaiE:)]

Attachment: cert-dump.txt

text dump of certificate "1"

Comment 12

[Kai Engert (:KaiE:)]

Just quoting as a reference:

From https://tools.ietf.org/html/rfc5280#section-4.1.2.3 :

 "4.1.2.3.  Signature

  This field contains the algorithm identifier for the algorithm used
  by the CA to sign the certificate.
  This field MUST contain the same algorithm identifier as the
  signatureAlgorithm field in the sequence Certificate (Section
  4.1.1.2)."

Comment 13

[Kai Engert (:KaiE:)]

(In reply to chenchu from comment #0)
> As for the certificate "1.pem", its signature algorithm identifier (SAI)
> Sha256WithRSAEncryption in tbsCertificate.signature and SAI
> Sha1WithRSAEncryption  in Certificate.signatureAlgorithm are different. NSS
> only looks at Certificate.signatureAlgorithm.

So, there are two elements inside the certificate, which seem redundant.

The "signatureAlgorithm" in the "outer" wrapper around the certificate, which is part of the signature created by the CA, seems to be more important. It is the one accessed by NSS, because it is expected to match the raw signature data that follows it.

The "inner" attribute "Signature" (just an identifier) is required to repeat the identifier that is used in the "outer" part in the "signatureAlgorithm" attribute.


The RFC clearly requires both fields to be identical, so I agree that for correctness, NSS should reject this attribute.


> Policy checks prohibiting weak signature will pass and such certificates are
> exploitable by hackers.

Can you please elaborate? Why exploitable? Which policy checks?

Comment 14

[Kai Engert (:KaiE:)]

(In reply to Kai Engert (:kaie:) from comment #13)
> 
> > Policy checks prohibiting weak signature will pass and such certificates are
> > exploitable by hackers.
> 
> Can you please elaborate? Why exploitable? Which policy checks?

Comment 15

[Kai Engert (:KaiE:)]

(In reply to Daniel Veditz [:dveditz] from comment #9)
> Kai: does Red Hat need a fix for this in NSS?

Thanks Dan for bringing this to my attention.

I think it would be good to fix this for correctness, although it's not yet clear to me how this could be a problem.

Comment 16

[chenchu]

@Kai
Some weak digest and encryption algorithms which can be cracked are forbidden by some policy checks. If a verifier only checks tbsCertificate.signature, certificates with strong tbsCertificate.signature but weak certificate.signatureAlgorithm will pass through policy checks. Hackers may crack such certificates and launch MITM attacks.

Comment 17

[Hubert Kario]

From what I know, checkers generally look at certificate.signatureAlgorithm (if there are any counter-examples, I'd love to see them). As Kai said, that's what NSS does. It's also what OpenSSL does (if they still accept certificates with mismatched algorithm identifiers).

So while yes, it's a bug, I don't think it's exploitable in deployed software, so it looks like a low priority issue to me.

Comment 18

[chenchu]

@Hubert
In our testing, Chrome, IE and NSS accept such a certificate while OpenSSL, mbedTLS, GnuTLS, wolfSSL, matrixSSL, Firefox, Safari reject it. 

We reported it to Google, Microsoft and NSS. Google Security Team has confirmed it as a security bug and fixed it on Chrome v58.0.3029.81. Microsoft has confirmed our reports on IE. 

One of our friends said that he found the similar bug in early OpenSSL but in our testing OpenSSL v1.0.1u, v1.0.2j and v1.1.0b reject such a certificate.  The possible reason is that OpenSSL has fixed it.

Thank you!

Comment 19

[Hubert Kario]

But why they reject it? Because it is malformed or because it is using deprecated signature algorithm (sha-1)?

And will Chrome, IE and NSS accept such certificate if the hashes are sha-256 and md-5 instead of sha-256 and sha-1? Remember that manually installed CAs are treated differently by basically all browsers, e.g. IE will allow SHA-1 signatures from such CA's.

Comment 20

[chenchu]

In theory, the reasons that they reject it can be found in messages that they show. Unfortunately, the messages are not perfect as expected. For example, Safari shows the message "An error has occurred. Unable to import an item. The contents of this item cannot be retrieved". The reason why the content cannot be retrieved is not clarified. If the message shows that it is malformed or uses deprecated signature algorithm, the conclusion can be drawn that both tbsCertificate.signature and certificate.signatureAlgorithm are checked. We understand what you mean. The study of whether they do the right thing for the right reason is in our plan.
 
We know the fact that different SSL/TLS implementations or browsers adopt different policies for version, MD2, MD4, MD5, MD6, SHA-0, SHA-1, SHA-2 (224, 256, 384, 512, 512/224, 512/256), SHA-3 etc. Anyway, a certificate with mismathced signature algorithms should be rejected regardless of different policies.

Comment 21

[Hubert Kario]

(In reply to chenchu from comment #20)
> Anyway, a certificate
> with mismathced signature algorithms should be rejected regardless of
> different policies.

I completely agree.

But the reason why they are rejected is a difference between just a hardening fix (what it appears to be for NSS right now) and a security vulnerability (the case when for policy enforcement for MD5 and SHA-1 deprecation checks just the tbsCertificate.signature and mismatch is ignored).

In other words, it has significant impact on urgency of the issue.

Comment 22

[chenchu]

Attachment: 2.pem

Comment 23

[chenchu]

Attachment: mismatched_sha1_sha256.pem

Comment 24

[chenchu]

@Hubert Thank you for your reply which makes it clear to us what you and your team focus on. 
 
We attached two certificates to this report. 
 
Our certificate "2.pem" which has a strong tbsCertificate.signature (Sha-256) and a weak Certificate.signatureAlgorithm (Sha-1) is accepted by NSS, Chrome and IE but rejected by others.

The certificate "mismatched_sha1_sha256.pem" with a strong tbsCertificate.signature and a weak Certificate.signatureAlgorithm was generated and used by Google Security Team to confirm our report as a security bug.

For example, OpenSSL rejects such certificates for  "error 7 at 0 depth lookup:certificate signature failure". It checks not only tbsCertificate.signature but also Certificate.signatureAlgorithm.

Therefore, it should be the latter case i.e. a security vulnerability in your reply.  

Thank you!

Comment 25

[Hubert Kario]

(In reply to chenchu from comment #24)
> Our certificate "2.pem" which has a strong tbsCertificate.signature
> (Sha-256) and a weak Certificate.signatureAlgorithm (Sha-1) is accepted by
> NSS, Chrome and IE but rejected by others.

What makes you think that NSS considers SHA-1 to be a weak signature algorithm? Firefox and NSS use different policies.

Comment 26

[chenchu]

It is a relative concept. Please refer to such websites as https://betanews.com/2017/02/23/sha-1-collision-google/.

Comment 27

[chenchu]

Why do Firefox and NSS both of which are products of Mozilla adopt different policies?

Comment 28

[Hubert Kario]

I don't know what's the official Mozilla stance on that.

The fact remains, NSS considers SHA-1 signatures to be trustworthy. So to verify that mismatched signature algorithms are an issue, we need either a sha-1/md5 certificate or a sha-256/md5 certificate.

Also, please note that certutil by default won't reject certificate because of deprecated signature algorithm. The option -e needs to be added to command line for it to do that, e.g.:

   certutil -V -e -n 1 -d ./ -u S

Comment 29

[Daniel Veditz [:dveditz]]

(In reply to chenchu from comment #27)
> Why do Firefox and NSS both of which are products of Mozilla adopt different
> policies?

Because NSS is a library used by many different products, both client and server, and Firefox is specifically a web browser. NSS is configurable because different programs using that library want different policies. With respect to PKIX specifically, there is some hope we can contribute the "mozpkix" code back to the shared NSS library.

Comment 30

[John Schanck [:jschanck]]

Attachment: Bug 1366464 - compare signature and signatureAlgorithm fields in legacy certificate verifier. r=#nss-reviewers

Comment 31

[John Schanck [:jschanck]]

https://hg.mozilla.org/projects/nss/rev/b572fe296d47e9f9b7e97e69c6ade6dc6e5a730a

Comment 32

[Benjamin Beurdouche [:beurdouche]]

https://hg.mozilla.org/projects/nss/rev/b6b18d0259e73e3ccba160a479e9d098474bce6d (NSS 3.79.1)