A cryptographic library set NSS Mozilla (Network Security Services) has been identified in the critical vulnerability (( CVE-2021-43527 CVE-2021-43527)) that could lead to malicious code execution when processing DSA or RSA-PSS digital signatures specified using the DER ( Distinguished Encoding Rules). The issue codenamed BigSig has been fixed in NSS 3.73 and NSS ESR 3.68.1. Distribution package updates are available for Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Updates for not yet available Fedora are.
The problem manifests itself in applications that use NSS to handle CMS, S / MIME, PKCS # 7 and PKCS # 12 digital signatures, or when verifying certificates in TLS, X.509, OCSP, and CRL implementations. The vulnerability could surface in various client and server applications with TLS, DTLS and S / MIME support, email clients and PDF viewers that use the CERT_VerifyCertificate () NSS call to verify digital signatures.
as examples of vulnerable applications are mentioned LibreOffice, Evolution and Evince . Potentially, the problem can 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, Oracle Directory Server Enterprise Edition. At the same time, the vulnerability does not appear in Firefox, Thunderbird and Tor Browser, which use a separate library for verification mozilla :: pkix , which is also part of NSS. Chromium-based browsers (unless specifically compiled with NSS), which used NSS until 2015, but then were transferred to BoringSSL, are not affected by the problem.
The vulnerability is caused by an error in the certificate verification code in the function vfy_CreateContext from the secvfy.c file. The error manifests itself both when the client reads the certificate from the server, and when the server processes client certificates. When 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, for DSA and RSA-PSS signatures, the size is incorrectly checked, which leads to an overflow of the buffer allocated for the structure VFYContextStr 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 can be traced back to 2003, but it did not pose a threat until refactoring in 2012. In 2017, the same error was made when implementing RSA-PSS support. To carry out an attack, a resource-intensive generation of certain keys is not required to obtain the necessary data, since the overflow occurs at the stage before the validity of the digital signature is verified. The out-of-bounds piece of data is written to a memory area containing function pointers, making it easier to create working exploits.
The vulnerability was identified by researchers from Google Project Zero during experiments with new methods of fuzzing testing 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 maintained by an experienced security team using state-of-the-art testing and error analysis techniques. There are several programs in place to pay substantial rewards for identifying vulnerabilities in the NSS.
- NSS was one of the first projects to join the initiative Google oss-fuzz and was also tested in Mozilla’s libFuzzer-based fuzzing testing system.
- The library code has been checked many times in various static analyzers, including, since 2008, it has been monitored by the Coverity service.
- Until 2015, NSS was used in Google Chrome and independently from Mozilla was checked by the Google team (since 2015, Chrome switched to BoringSSL, but support for the NSS-based port remains).
The main problems due to which the problem went unnoticed for a long time:
- NSS unit library and fuzzing testing was not carried out as a whole, but at the level of individual components. For example, the code for decoding DER and processing certificates was separately checked – in the course of 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, strict limits on the size of the output (10,000 bytes) were set in the absence of such limitations in NSS (many structures in normal mode could have a size of more than 10,000 bytes, therefore, to identify problems, a larger amount of input data was required). For a full check, the limit should have been 2 24 -1 bytes (16 MB), which corresponds to the maximum size of a certificate allowed in TLS.
- Misconception about code coverage by fuzzing testing. The vulnerable code was actively tested, but using fuzers, which were not able to generate the required input data. For example, fuzzer tls_server_target used a predefined set of ready-made certificates, which limited the verification of the certificate verification code to only TLS messages and protocol state changes.
