1533216 - (CVE-2019-17007) CERT_DecodeCertPackage() crash with Netscape Certificate Sequences

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[taviso]

Attachment: crash testcase

I noticed that the main entrypoint for decoding DER blobs in NSS, CERT_DecodeCertPackage(), actually handles multiple formats including PEM, PKCS7, and old Netscape Certificate Sequences.

You can generate a Netscape Certificate Sequence with the OpenSSL nseq tool, I just did this:

$ openssl nseq -in mail.google.com.pem -toseq -out nseq.pem

I guessed that this format might not have been as well audited as others, so fuzzed it and it crashed with a NULL deref quickly.

Test case attached, I'm guessing this means any client or server that handles untrusted certificates can be crashed, I didn't try it against Firefox.

You can verify it like this:

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

I suppose this is a trivial denial of service issue against the network daemons that use NSS.

Comment 1

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

ASAN output here:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==7159==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00010fd77293 bp 0x7ffee02a3160 sp 0x7ffee02a3040 T0)
==7159==The signal is caused by a READ memory access.
==7159==Hint: address points to the zero page.
    #0 0x10fd77292 in SECITEM_CopyItem_Util secitem.c:275
    #1 0x10fea10e6 in collect_certs certread.c:500
    #2 0x10fea0cf9 in SEC_ReadCertSequence certread.c:207
    #3 0x10fe9f8ed in CERT_DecodeCertPackage certread.c:360
    #4 0x10fea0f46 in CERT_DecodeCertFromPackage certread.c:517
    #5 0x10f978d2d in AddCert certutil.c:112
    #6 0x10f97347e in certutil_main certutil.c:3845
    #7 0x10f968e46 in main certutil.c:4032
    #8 0x7fff6a147ed8 in start (libdyld.dylib:x86_64+0x16ed8)

==7159==Register values:
rax = 0x0000100000000000  rbx = 0x00007ffee02a3260  rcx = 0x0000000000000000  rdx = 0x0000000000000000
rdi = 0x00006080000047a0  rsi = 0x0000100000000000  rbp = 0x00007ffee02a3160  rsp = 0x00007ffee02a3040
 r8 = 0x00001c3a0000335a   r9 = 0x0000610000049b58  r10 = 0x00000001185d5208  r11 = 0x000000010fd77220
r12 = 0x0000000000001631  r13 = 0x00007ffee02a3aa0  r14 = 0x00007ffee02a3400  r15 = 0x00007ffee02a3440
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV secitem.c:275 in SECITEM_CopyItem_Util
==7159==ABORTING

Thank you for this.

Comment 2

[Martin Thomson [:mt:]]

The obvious question has to be asked: do we still need to support these? I'll ask on nss-dev.

Comment 3

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

SEC_ReadCertSequence (via CERT_DecodeCertPackage) takes a callback (in this case, collect_certs) that it calls with a pointer to an array of pointers to SECItems corresponding to any encoded certificates it found. It looks like it's possible to get it to allocate this array but not fill it out (e.g. if the data consists of an empty SEQUENCE) (I'm seeing an array with a single null pointer, but maybe that's just luck). In any case, SEC_ReadCertSequence calls the callback with this empty array and a count of 0, which collect_certs ignores and attempts to copy the SECItem it thinks is present, resulting in a null deref. Seems like collect_certs should at least check its given count and return an error, although I imagine there might be more bugs in these functions.

Comment 4

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

Attachment: Bug 1533216 - check we actually got some certs in collect_certs r?jcj

Comment 5

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

https://hg.mozilla.org/projects/nss/rev/1473dd7efe2ce4f8722a33ebb03a3425e09887de

Comment 6

[Huzaifa Sidhpurwala]

Are we planning to assign a CVE to this? Assuming this a a null pointer deref, where a client can present a malicious cert to a server and crash it or the other way around.

Comment 7

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

(In reply to Huzaifa Sidhpurwala from comment #6)

Are we planning to assign a CVE to this? Assuming this a a null pointer deref, where a client can present a malicious cert to a server and crash it or the other way around.

If you'd like one assigned for tracking purposes, we certainly can, and update the relnotes retroactively: Just needinfo [e-mail]

Comment 8

[Huzaifa Sidhpurwala]

Needinfo'ing [e-mail] for assigning a CVE and updating relnotes.