The news about identifying a critical vulnerability (already listed under CVE-2021-43527) en the set of cryptographic libraries NSS (Network security services) from Mozilla that could lead to the execution of malicious code when processing DSA or RSA-PSS digital signatures specified using DER (Distinguished Encoding Rules).
The problem manifests itself in applications that use NSS to handle digital signatures CMS, S / MIME, PKCS # 7 and PKCS # 12, or when verifying certificates in deployments TLS, X.509, OCSP and CRL. The vulnerability could arise in various client and server applications with TLS, DTLS, and S / MIME support, email clients, and PDF viewers that use the NSS CERT_VerifyCertificate () call to verify digital signatures.
LibreOffice, Evolution and Evince are mentioned as examples of vulnerable applications. Potentially, the problem can also affect projects such as Pidgin, Apache OpenOffice, Suricata, Curl, among others.
At the same time, the vulnerability does not appear in Firefox, Thunderbird and Tor Browser, which use a separate mozilla :: pkix library for verification, which is also part of NSS. The Chrome-based browsers (unless they were specifically compiled with NSS), which used NSS until 2015, but then carried over to BoringSSL, they are not affected by the problem.
The vulnerability is due to a bug in the certificate verification code in the vfy_CreateContext function of the secvfy.c file. The error manifests itself both when the client reads the certificate from the server as when the server processes the client's 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 post-processing, for DSA and RSA-PSS signatures, the size is incorrectly verified, resulting in which leads to an overflow of the allocated buffer 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 verified that the signature can be larger).
The code that contains the vulnerability dates back to 2003, but it was not a threat until refactoring in 2012. In 2017, the same mistake 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 in the stage prior to the verification of the validity of the digital signature. The out-of-bounds portion of the data is written to a memory area that contains function pointers, making it easy to create working exploits.
The vulnerability was identified by Google Project Zero researchers during experiments with new fuzzing testing methods and is a good demonstration of how trivial vulnerabilities can go undetected for a long time in a widely tested known project.
As for main problems for which the problem went unnoticed for a long time:
- The NSS drive library and fuzzing tests were not carried out in its entirety, but at the individual component level.
- For example, the code to decode DER and process certificates was verified separately; In the course of the 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 was not revealed.
- During the fuzzing tests, strict limits were set on the size of the output (10,000 bytes) in the absence of such limitations in NSS (many structures in normal mode could be larger than 10,000 bytes, therefore, to identify problems , more input data required). For full verification, 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 tests. The vulnerable code was actively tested, but using fuzers, which were unable to generate the required input data. For example, fuzzer tls_server_target used a predefined set of out-of-the-box certificates, which limited the verification of the certificate verification code to only TLS messages and protocol state changes.
Finally, It is worth mentioning that the problem with codename BigSig has been fixed in NSS 3.73 and NSS ESR 3.68.1 and the updates of the solution in package form have already been released in the different distributions: Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD, etc.
If you want to know more about it, you can consult the following link.