A critical vulnerability (CVE-2021-43527) has been identified in the set of cryptographic libraries NSS (Network Security Services) developed by Mozilla. This vulnerability may allow an attacker to execute code when processing DSA or RSA-PSS digital signatures encoded using the DER (Distinguished Encoding Rules) encoding method. The issue, codenamed BigSig, has been addressed in NSS versions 3.73 and NSS ESR 3.68.1. Package updates are available for Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, and FreeBSD distributions. Updates for Fedora are not yet available.
The problem manifests in applications using NSS to process digital signatures for CMS, S/MIME, PKCS #7, and PKCS #12, or when verifying certificates in TLS, X.509, OCSP, and CRL implementations. The vulnerability could arise in various client and server applications supporting TLS, DTLS, and S/MIME, email clients, and PDF viewers that use the NSS call CERT_VerifyCertificate() to validate digital signatures.
Examples of vulnerable applications include LibreOffice, Evolution, and Evince. The issue may potentially also affect projects such as Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss for the Apache HTTP server, Oracle Communications Messaging Server, and Oracle Directory Server Enterprise Edition. However, the vulnerability does not affect Firefox, Thunderbird, and Tor Browser, which use a separate library mozilla::pkix for verification, also part of NSS. Chromium-based browsers are not affected (unless specifically built with NSS), having transitioned to BoringSSL after using NSS until 2015.
The vulnerability is caused by an error in the certificate verification code in the vfy_CreateContext function located in secvfy.c. The error manifests when reading a client certificate from the server and during the processing proxy server of client certificates. During the verification of a digital signature encoded using DER, NSS decodes the signature into a fixed-size buffer and passes this buffer to the PKCS #11 module. During further processing, for DSA and RSA-PSS signatures, the size is incorrectly verified, leading to a buffer overflow in the VFYContextStr structure if the digital signature size exceeds 16384 bits (the buffer is allocated 2048 bytes, but it is not checked that the signature may be larger).
The vulnerable code has been tracked since 2003, but it did not pose a threat until the refactoring done in 2012. In 2017, the same mistake occurred during the implementation of RSA-PSS support. Performing the attack does not require resource-intensive generation of certain keys to obtain the necessary data, as the overflow occurs prior to checking the validity of the digital signature. The out-of-bounds data is written to the memory area containing function pointers, which simplifies the creation of working exploits.
The vulnerability was discovered by researchers from Google Project Zero during experiments with new fuzzing testing methods and is a good demonstration of how trivial vulnerabilities can remain unnoticed for a long time in a widely tested well-known project:
- The NSS code is accompanied by an experienced team responsible for security, applying modern testing and error analysis methods. There are several programs in place offering significant rewards for identifying vulnerabilities in NSS.
- NSS was one of the first projects to join the Google oss-fuzz initiative and was also tested in the Mozilla developed fuzzing testing system based on libFuzzer.
- The code of the library has been repeatedly checked in various static analyzers, including being tracked by the Coverity service since 2008.
- Until 2015, NSS was used in Google Chrome and independently checked by Google's team (since 2015, Chrome transitioned to BoringSSL, but support for the NSS-based port remains).
The main issues that caused the problem to go unnoticed for so long were:
- NSS is a modular library, and fuzzing testing was not conducted as a whole but rather at the level of individual components. For example, the code for decoding DER and processing certificates was checked separately — during fuzzing, it was quite possible to obtain a certificate that triggered the vulnerability in question, but its verification did not reach the verification code, and thus the issue went undetected.
- During fuzzing testing, strict limits were set on the output size (10,000 bytes), while no such restrictions existed in NSS (many structures could normally exceed 10,000 bytes, which required a larger volume of input data to uncover issues). For a comprehensive check, the limit should have been 224-1 bytes (16 MB), corresponding to the maximum certificate size allowed in TLS.
- There was a misconception about the code coverage achieved through fuzzing testing. Vulnerable code was actively tested, but it utilized fuzzers that were unable to generate the required input data. For instance, the fuzzer tls_server_target used a predefined set of ready-made certificates, limiting the verification code testing to only TLS messages and protocol state changes.
Source: opennet.ru
