Kritikus sérülékenységet (CVE-2021-43527) azonosítottak a Mozilla által kifejlesztett NSS (Network Security Services) kriptográfiai könyvtárkészletben, amely támadó kódjának végrehajtásához vezethet a DSA vagy RSA-PSS digitális aláírások feldolgozása során. a DER kódolási módszer (Distinguished Encoding Rules). A BigSig kódnevű problémát az NSS 3.73 és az NSS ESR 3.68.1 javítja. A disztribúciókban található csomagfrissítések elérhetők Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo és FreeBSD számára. Még nem érhetők el frissítések a Fedorához.
A probléma azoknál az alkalmazásoknál jelentkezik, amelyek NSS-t használnak a CMS, S/MIME, PKCS #7 és PKCS #12 digitális aláírások kezelésére, vagy a tanúsítványok ellenőrzésekor a TLS, X.509, OCSP és CRL megvalósításokban. A sérülékenység a TLS-t, DTLS-t és S/MIME-t támogató különféle kliens- és szerveralkalmazásokban, e-mail kliensekben és PDF-megtekintőkben jelenhet meg, amelyek az NSS CERT_VerifyCertificate() hívást használják a digitális aláírások ellenőrzésére.
A sebezhető alkalmazások példájaként a LibreOffice, az Evolution és az Evince szerepel. A probléma potenciálisan olyan projekteket is érinthet, mint a Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss az Apache http szerverhez, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. A sérülékenység azonban nem jelenik meg a Firefoxban, a Thunderbirdben és a Tor Browserben, amelyek külön, az NSS-ben is szereplő mozilla::pkix könyvtárat használnak az ellenőrzéshez. A 2015-ig NSS-t használó, de utána BoringSSL-re váltott Chromium alapú böngészőket (hacsak nem kifejezetten NSS-sel építették) szintén nem érinti a probléma.
A biztonsági rést a secvfy.c fájl vfy_CreateContext függvényében található tanúsítvány-ellenőrző kód hibája okozza. A hiba akkor fordul elő, amikor az ügyfél beolvas egy tanúsítványt a kiszolgálóról, és amikor a kiszolgáló feldolgozza az ügyféltanúsítványokat. A DER-kódolt digitális aláírás ellenőrzésekor az NSS dekódolja az aláírást egy rögzített méretű pufferbe, és továbbítja a puffert a PKCS #11 modulnak. A további feldolgozás során a méret hibásan ellenőrzi a DSA és RSA-PSS aláírásokat, ami a VFYContextStr struktúrához lefoglalt puffer túlcsordulásához vezet, ha a digitális aláírás mérete meghaladja az 16384 bitet (2048 bájt van lefoglalva a puffer számára, de nincs ellenőrizve, hogy az aláírás nagyobb lehet) ).
A sérülékenységet tartalmazó kód 2003-ig vezethető vissza, de egy 2012-ben végrehajtott átalakításig nem jelentett veszélyt. 2017-ben ugyanez a hiba történt az RSA-PSS támogatás bevezetésekor. A támadás végrehajtásához nem szükséges bizonyos kulcsok erőforrás-igényes generálása a szükséges adatok megszerzéséhez, mivel a túlcsordulás a digitális aláírás helyességének ellenőrzése előtti szakaszban történik. Az adatok határokon túlmutató része a függvényekre mutatókat tartalmazó memóriaterületre íródik, ami leegyszerűsíti a működő exploitok létrehozását.
A sebezhetőséget a Google Project Zero kutatói fedezték fel, miközben új, zavaros tesztelési módszerekkel kísérleteztek, és ez jól mutatja, hogy a triviális sebezhetőségek hogyan maradhatnak sokáig észrevétlenül egy széles körben tesztelt, jól ismert projektben:
- Az NSS-kódot egy tapasztalt biztonsági csapat karbantartja a legmodernebb tesztelési és hibaelemzési technikákkal. Számos program létezik, amelyek jelentős jutalmat fizetnek az NSS sebezhetőségeinek azonosításáért.
- Az NSS volt az egyik első projekt, amely csatlakozott a Google oss-fuzz kezdeményezéséhez, és a Mozilla libFuzzer alapú fuzz-tesztelő rendszerében is tesztelték.
- A könyvtár kódját sokszor ellenőrizték különböző statikus analizátorokban, többek között 2008 óta a Coverity szolgáltatás is felügyeli.
- 2015-ig az NSS-t a Google Chrome-ban használták, és a Google csapata a Mozillától függetlenül ellenőrizte (2015 óta a Chrome BoringSSL-re váltott, de az NSS-alapú port támogatása továbbra is megmarad).
A fő problémák, amelyek miatt a probléma hosszú ideig észrevétlen maradt:
- Az NSS moduláris könyvtár és a fuzzing tesztelés nem teljes egészében, hanem az egyes komponensek szintjén történt. Például külön ellenőrizték a DER dekódolására és a tanúsítványok feldolgozására szolgáló kódot - a fuzzing során lehetett volna olyan tanúsítványt szerezni, amely a kérdéses sérülékenység megnyilvánulásához vezet, de az ellenőrzése nem érte el az ellenőrző kódot, és a probléma nem felfedi magát.
- A fuzzing tesztelés során szigorú korlátozásokat állítottak be a kimeneti méretre (10000 10000 bájt), hasonló korlátozások hiányában az NSS-ben (sok struktúra normál módban 224 1 bájtnál is nagyobb lehet, ezért több bemeneti adatra volt szükség a problémák azonosításához) . A teljes ellenőrzéshez a korlátnak 16-XNUMX bájtnak (XNUMX MB) kellett volna lennie, ami megfelel a TLS-ben megengedett maximális tanúsítványméretnek.
- Tévhit a fuzz tesztelési kód lefedettségéről. A sebezhető kódot aktívan tesztelték, de olyan fuzzerekkel, amelyek nem tudták előállítani a szükséges bemeneti adatokat. Például a fuzzer tls_server_target egy előre meghatározott kész tanúsítványkészletet használt, amely a tanúsítvány-ellenőrző kód ellenőrzését csak a TLS-üzenetekre és a protokollállapot-változásokra korlátozta.
Forrás: opennet.ru