1576307 - NSS: RC2 CBC encryption OOB read if IV is too small

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Guido Vranken]

Attachment: poc_rc2_oob_iv.cpp

I'm gonna go ahead and file my findings of memory bugs in NSS here. Again apologies if it doesn't belong here.

=================================================================
==8786==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000738 at pc 0x00000097534c bp 0x7ffc508cf350 sp 0x7ffc508cf348
READ of size 2 at 0x602000000738 thread T0
#0 0x97534b in RC2_InitContext /home/jhg/nss/nss/out/Debug/../../lib/freebl/alg2268.c:156:9
#1 0x978060 in RC2_CreateContext /home/jhg/nss/nss/out/Debug/../../lib/freebl/alg2268.c:209:24
#2 0x6a4d2c in sftk_CryptInit /home/jhg/nss/nss/out/Debug/../../lib/softoken/pkcs11c.c:901:17
#3 0x6a2944 in NSC_EncryptInit /home/jhg/nss/nss/out/Debug/../../lib/softoken/pkcs11c.c:1269:12
#4 0x5ef88b in PK11_Encrypt /home/jhg/nss/nss/out/Debug/../../lib/pk11wrap/pk11obj.c:971:11
#5 0x5197a5 in main /home/jhg/nss/cryptofuzz/poc_rc2_oob_iv.cpp:46:5
#6 0x7fbaa3588b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#7 0x41c739 in _start (/home/jhg/nss/cryptofuzz/a.out+0x41c739)

Comment 1

[Daniel Veditz [:dveditz]]

JC: can a malicious client or server intentionally use a too-small IV against an NSS client/server, or is this only available to raw NSS calls? In other words, is this something Firefox has to worry about or is it a technical problem in NSS for other clients to worry about?

Comment 2

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

Kevin?

Comment 3

[Kevin Jacobs [:kjacobs]]

Thanks for the report, Guido.

Dan - Firefox doesn't enable any TLS ciphersuite that uses RC2. PKCS12 client cert import can hit RC2, but it's not vulnerable to this bug.

The POC passes an ivvec of length 8 to PK11_Encrypt via the *param argument. The implementation assumes this will be a pointer to an rc2_param struct at https://searchfox.org/mozilla-central/source/security/nss/lib/softoken/pkcs11c.c#898. Note that other algorithms make the same assumption and should be fixed.

I think it's unlikely that Firefox is vulnerable to this, as it's responsible for allocating the appropriate structs prior to calling individual PKCS11 functions (for example, the PKCS12 import case: https://searchfox.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11mech.c#882-890. Webcrypto and TLS do their own).

Unless I've missed another path, this is only a concern for other NSS users.

Comment 4

[Kevin Jacobs [:kjacobs]]

Attachment: Bug 1576307 - Check mechanism param and param length before casting to mechanism-specific structs. r?jcj

Comment 5

[Daniel Veditz [:dveditz]]

since this was made a "P1" I'll assume this must be sec-high for some other nss consumer.

Comment 6

[Kevin Jacobs [:kjacobs]]

We marked it P1 since we have a straightforward patch. The issue itself we agreed is sec-low, but I hadn't yet updated the bug.

Sorry about that.

Comment 7

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

https://hg.mozilla.org/projects/nss/rev/53d92a32408049038f450aa747b0030607988230

Comment 8

[Kevin Jacobs [:kjacobs]]

Attachment: Bug 1576307 - Fixup for fips tests, permit NULL iv as necessary.

ECB mode should not require an IV.

Comment 9

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

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