1735028 - (CVE-2022-22747) CERT_DecodeCertPackage() crash with empty pkcs7 sequence

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[taviso]

Attachment: nss-empty-pkcs7.der

This is similar to bug 1533216, I found another case where CERT_DecodeCertPackage() can fail. As far as I know, this can crash any client or server that accepts untrusted certificates because this is the standard entrypoint for getting a CERT object from some data read off the wire.

I'm surprised this wasn't caught by fuzzing, but if you put an indefinite sequence containing just a pkcs7 signedData OID, followed by a NULL or EOC or something similar, SEC_ReadPKCS7Certs() will dump core.

$ certutil -d "." -A -n test -t "p,p,p" -i nss-empty-pkcs7.der 
Segmentation fault

Comment 1

[John Schanck [:jschanck]]

Attachment: Bug 1735028 - check for missing signedData field r=keeler

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Daniel Veditz [:dveditz]]

Updating the Firefox status fields: It looks like this was included in NSS 3.68.1 so it'll be fixed in Firefox ESR91.4. Also fixed in NSS 3.73 which means Firefox release 96 will be the fixed one.

Comment 4

[Daniel Veditz [:dveditz]]

Technically these won't be checked in until tomorrow. I'll reopen until we have a commit link to add to the bug

Comment 5

[Ryan VanderMeulen [:RyanVM]]

We're also not planning to respin the Firefox 91.4.0esr build for NSS 3.68.1, just TB 91.4.0.

Comment 6

[Benjamin Beurdouche [:beurdouche]]

https://hg.mozilla.org/projects/nss/rev/7ff99e71f3e37faed12bc3cc90a3eed27e3418d0 (default)
https://hg.mozilla.org/projects/nss/rev/5b2659c39cc7c22f2e403e90fc75189cd5023310 (3.68.1)
https://hg.mozilla.org/projects/nss/rev/2adbe73d88e016b6604e1014731d8c22d6e58005 (3.73)

Comment 7

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Are we sure this here was really just a crash?

Comment 8

[John Schanck [:jschanck]]

I think so. It's a null pointer dereference where we explicitly initialize the pointer to NULL. I don't see a way to trigger anything more severe---like dereferencing an uninitialized pointer or an attacker controlled pointer.