A critical vulnerability (CVE-2021-43527) has been identified in a set of NSS (Network Security Services) cryptographic libraries developed by Mozilla, which can lead to the execution of malicious code when processing DSA or RSA-PSS digital signatures specified using the DER encoding method ( Distinguished Encoding Rules). The issue, codenamed BigSig, has been fixed in the NSS 3.73 and NSS ESR 3.68.1 releases. Distribution package updates are available for Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. There are no updates available for Fedora yet.
The problem manifests itself in applications that use NSS to process CMS, S/MIME, PKCS #7, and PKCS #12 digital signatures, or to verify certificates in TLS, X.509, OCSP, and CRL implementations. The vulnerability may surface in various TLS, DTLS and S/MIME-enabled client and server applications, email clients and PDF viewers that use the CERT_VerifyCertificate() NSS call to verify digital signatures.
LibreOffice, Evolution and Evince are mentioned as examples of vulnerable applications. The problem can also potentially affect projects such as Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss for Apache http server, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. At the same time, the vulnerability does not appear in Firefox, Thunderbird, and Tor Browser, which use a separate mozilla::pkix library, which is also part of NSS, for verification. Chromium-based browsers (unless they are specifically built with NSS) that used NSS until 2015, but then switched to BoringSSL, are also not affected by the problem.
The vulnerability is caused by an error in the certificate verification code in the vfy_CreateContext function from the secvfy.c file. The error occurs both when the client reads the certificate from the server, and when the server processes client certificates. In the process of verifying a DER-encoded digital signature, NSS decodes the signature into a fixed size buffer and passes this buffer to the PKCS #11 module. During further processing, the size of the DSA and RSA-PSS signatures is incorrectly checked, which leads to an overflow of the buffer allocated for the VFYContextStr structure if the size of the digital signature exceeds 16384 bits (2048 bytes are allocated for the buffer, but it is not checked that the signature can be larger ).
The code containing the vulnerability has been traced since 2003, but it did not pose a threat until the refactoring carried out in 2012. In 2017, the same mistake was made when implementing RSA-PSS support. The attack does not require resource-intensive generation of certain keys to obtain the necessary data, since the overflow occurs at the stage before checking the correctness of the digital signature. The out-of-bounds part of the data is written to a memory area containing function pointers, which simplifies the creation of working exploits.
The vulnerability was discovered by Google Project Zero researchers while experimenting with new fuzz testing methods and is a good demonstration of how trivial vulnerabilities can go unnoticed for a long time in a widely tested well-known project:
- The NSS code is backed up by an experienced security team using state-of-the-art testing and error analysis techniques. There are several programs that provide substantial rewards for identifying vulnerabilities in NSS.
- NSS was one of the first projects involved in Google's oss-fuzz initiative and was also tested in Mozilla's libFuzzer-based fuzzing testing system.
- The library code has been repeatedly checked in various static analyzers, including since 2008 it has been tracked by the Coverity service.
- Until 2015, NSS was used in Google Chrome and was independently verified by the Google team from Mozilla (Chrome switched to BoringSSL in 2015, but NSS-based port support remains).
The main problems due to which the problem went unnoticed for a long time:
- NSS is a modular library and fuzzing testing was not carried out as a whole, but at the level of individual components. For example, the DER decoding code and certificate processing code were checked separately - during fuzzing, a certificate could well have been obtained, leading to the manifestation of the vulnerability in question, but its verification did not reach the verification code and the problem did not reveal itself.
- During fuzzing testing, hard limits were set on the output size (10000 bytes) in the absence of such restrictions in NSS (many structures in normal mode could have a size of more than 10000 bytes, so more input data was required to identify problems). For full verification, the limit should have been 224-1 bytes (16 MB), which corresponds to the maximum certificate size allowed in TLS.
- Misconception about code coverage by fuzzing testing. The vulnerable code was actively tested, but using fuzzers that were not able to generate the necessary input data. For example, the fuzzer tls_server_target used a predefined set of out-of-box certificates, which limited the verification of the certificate verification code to only TLS messages and protocol state changes.
Source: opennet.ru