A Mozilla által fejlesztett NSS (Network Security Services) kriptográfiai könyvtárgyűjteményében kritikus sebezhetőséget (CVE-2021-43527) fedeztek fel, amely lehetővé teheti a támadó számára a kód végrehajtását digitális aláírások DSA vagy RSA-PSS feldolgozása során, amelyeket DER (Distinguished Encoding Rules) kódolási módszerrel állítanak elő. A BigSig kódnévvel ellátott problémát az NSS 3.73 és az NSS ESR 3.68.1 verziókban javították. A Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo és FreeBSD disztribúciókhoz elérhetők a csomagfrissítések. Jelenleg a Fedora számára nem elérhetők frissítések.
A probléma azokban az alkalmazásokban jelentkezik, amelyek az NSS-t használják CMS, S/MIME, PKCS #7 és PKCS #12 digitális aláírások feldolgozására, vagy tanúsítványok érvényesítésére TLS, X.509, OCSP és CRL megvalósításokban. A sebezhetőség felmerülhet különböző ügyfél- és kiszolgálóalkalmazásokban, amelyek támogatják a TLS-t, DTLS-t és S/MIME-t, valamint olyan levelezőprogramokban és PDF-olvasókban, amelyek az NSS CERT_VerifyCertificate() hívását használják a digitális aláírások ellenőrzésére.
A sebezhető alkalmazások közé tartozik a LibreOffice, az Evolution és az Evince. A probléma potenciálisan érintheti a következő projekteket is: Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss az Apache webkiszolgáló számára, Oracle Communications Messaging Server és az Oracle Directory Server Enterprise Edition. A Firefox, a Thunderbird és a Tor Browser nem érintett, mivel a hitelesítéshez külön könyvtárat, a mozilla::pkix-et használják, amely szintén az NSS része. A Chromium-alapú böngészők sem érzékenyek (ha nem kifejezetten NSS-sel fordították őket), amelyek 2015 előtt használták az NSS-t, de azóta BoringSSL-re álltak át.
A sebezhetőség a tanúsítványok ellenőrzésének hibájából adódik a vfy_CreateContext funkcióban, a secvfy.c fájlban. A hiba a tanúsítvány ügyfél általi szerverről való olvasásakor és a feldolgozás során is megjelenik. szerverrel az ügyfelek tanúsítványaival kapcsolatban. A DER módszerrel kódolt digitális aláírás ellenőrzése során az NSS egy rögzített méretű puffert dekódol az aláírásba, és ezt a puffert továbbítja a PKCS #11 modulnak. A további feldolgozás során a DSA és RSA-PSS aláírásoknál a méretet hibásan ellenőrzik, ami a VFYContextStr struktúrához tartozó puffer túlcsordulásához vezet, ha a digitális aláírás mérete meghaladja a 16384 bitet (a puffer 2048 bájt méretű, de nem ellenőrzik, hogy az aláírás nagyobb méretű lehet).
A vulnerability in the code has been tracked since 2003, but it did not pose a threat until the refactoring conducted in 2012. In 2017, the same mistake occurred during the implementation of RSA-PSS support. The attack does not require resource-intensive generation of specific keys to obtain the necessary data, as the overflow occurs at a stage before the digital signature validity check. The overflowing data is written into the memory area that contains function pointers, making it easier to create functional exploits.
The vulnerability was identified by researchers from Google Project Zero during experiments with new fuzzing testing methods and serves as a good demonstration of how trivial vulnerabilities can remain unnoticed for a long time in a widely tested and well-known project.
- The NSS code is accompanied by an experienced security team that applies modern testing and debugging analysis methods. Several programs are in place to provide substantial rewards for discovering vulnerabilities in NSS.
- NSS was one of the first projects to join the Google oss-fuzz initiative and was also tested in Mozilla's fuzzing testing system based on libFuzzer.
- The library's code has been repeatedly checked against various static analyzers, including being monitored by Coverity since 2008.
- Until 2015, NSS was used in Google Chrome and was independently tested by the Google team (since 2015, Chrome has transitioned to BoringSSL, but support for the NSS-based port is maintained).
The main issues that caused the problem to remain unnoticed for a long time:
- The NSS is a modular library, and fuzzing tests were conducted not as a whole but at the level of individual components. For example, decoding DER and certificate processing code were checked separately — during fuzzing, a certificate could have been obtained that triggered the vulnerability in question, but its verification did not reach the verification code, and thus the problem went undetected.
- A fuzzing test imposed strict output size limits (10,000 bytes) while no such constraints existed in NSS (many structures could, under normal conditions, exceed 10,000 bytes, necessitating 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 permissible certificate size in TLS.
- Incorrect understanding of code coverage during fuzzing testing. Vulnerable code was actively tested, but using fuzzers incapable of generating the necessary input data. For example, the fuzzer tls_server_target employed a predefined set of ready-made certificates, which restricted the verification code testing to TLS messages and protocol state transitions.
Forrás: opennet.ru
