1879513 - HandleCertificateDecode causes Null-dereference

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Anna Weine]

https://oss-fuzz.com/testcase-detail/5816648133050368:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==185569==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000058 (pc 0x0000006ec36d bp 0x7ffd3c5b9750 sp 0x7ffd3c5b9700 T0)
==185569==The signal is caused by a WRITE memory access.
==185569==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x6ec36d in PK11_DigestOp nss/lib/pk11wrap/pk11cxt.c:1506:19
#1 0x5f34d0 in ssl3_UpdatePostHandshakeHashes nss/lib/ssl/ssl3con.c:4070:10
#2 0x6118f2 in ssl_HashHandshakeMessageInt nss/lib/ssl/ssl3con.c:12535:10
#3 0x6118f2 in ssl_HashPostHandshakeMessage nss/lib/ssl/ssl3con.c:12595:12
#4 0x586958 in tls13_HandleCertificateDecode nss/lib/ssl/tls13con.c:3866:14
#5 0x586958 in tls13_HandlePostHelloHandshakeMessage nss/lib/ssl/tls13con.c:1211:20
#6 0x612555 in ssl3_HandleHandshakeMessage nss/lib/ssl/ssl3con.c:12684:22

Comment 1

[Anna Weine]

As John mentioned (and I checked) the bug is happening when the code is trying to hash a buffer with shaPostHandshake being null.

The quick working fix could be this, but I am not happy about the fix, because as for me it does not solve the problem, but removes the consequences.

if (ss->ssl3.hs.shaPostHandshake == NULL)
    {
        ss->ssl3.hs.shaPostHandshake = PK11_CloneContext(ss->ssl3.hs.sha);
        if (ss->ssl3.hs.shaPostHandshake == NULL) {
            ssl_MapLowLevelError(SSL_ERROR_SHA_DIGEST_FAILURE);
            return SECFailure;
        }
    }

Comment 2

[Anna Weine]

The allocation of shaPostHandshake is happening either in tls13_SendCertificateRequest (https://searchfox.org/mozilla-central/source/security/nss/lib/ssl/tls13con.c#2677) or tls13_HandleCertificateRequest (https://searchfox.org/mozilla-central/source/security/nss/lib/ssl/tls13con.c#2989).

I don't immediately see how the certificate compression function causes this problem, as this function is somehow equivalent to HandleCertificate function. If the certificate is encoded we call tls13_HandleCertificateDecode, otherwise - tls13_HandleCertificate()

Comment 3

[Anna Weine]

Attachment: Bug 1879513 - Certificate Compression: enabling the check that the compression was advertised

Comment 4

[John Schanck [:jschanck]]

https://hg.mozilla.org/projects/nss/rev/2ab433f4efc059dc5995154c931164c40e7a6582

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Does this affect NSS 3.90 also (used in ESR115)?

Comment 6

[John Schanck [:jschanck]]

This was a short lived regression on NSS trunk. No NSS or Firefox releases were affected.