Natukoy ang isang kritikal na kahinaan (CVE-2021-43527) sa hanay ng mga cryptographic na library ng NSS (Network Security Services) na binuo ng Mozilla, na maaaring humantong sa pagpapatupad ng attacker code kapag nagpoproseso ng mga digital na lagda ng DSA o RSA-PSS na tinukoy gamit ang Paraan ng pag-encode ng DER ( Distinguished Encoding Rules). Ang isyu, na may codenamed na BigSig, ay nalutas sa NSS 3.73 at NSS ESR 3.68.1. Available ang mga update sa package sa mga distribusyon para sa Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Wala pang available na update para sa Fedora.
Ang problema ay nangyayari sa mga application na gumagamit ng NSS upang pangasiwaan ang mga digital na lagda ng CMS, S/MIME, PKCS #7 at PKCS #12, o kapag nagbe-verify ng mga certificate sa mga pagpapatupad ng TLS, X.509, OCSP at CRL. Maaaring lumitaw ang kahinaan sa iba't ibang mga application ng kliyente at server na sumusuporta sa TLS, DTLS at S/MIME, mga email client at PDF viewer na gumagamit ng tawag sa NSS CERT_VerifyCertificate() upang i-verify ang mga digital na lagda.
Ang LibreOffice, Evolution at Evince ay binanggit bilang mga halimbawa ng mga vulnerable na application. Posible, ang problema ay maaari ring makaapekto sa mga proyekto tulad ng Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss para sa Apache http server, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Gayunpaman, hindi lumalabas ang kahinaan sa Firefox, Thunderbird at Tor Browser, na gumagamit ng hiwalay na mozilla::pkix library, kasama rin sa NSS, para sa pag-verify. Ang mga browser na nakabatay sa Chromium (maliban kung ang mga ito ay partikular na binuo gamit ang NSS), na gumamit ng NSS hanggang 2015, ngunit pagkatapos ay lumipat sa BoringSSL, ay hindi rin apektado ng problema.
Ang kahinaan ay sanhi ng isang error sa certificate verification code sa vfy_CreateContext function mula sa secvfy.c file. Ang error ay nangyayari kapwa kapag ang kliyente ay nagbasa ng isang sertipiko mula sa server at kapag ang server ay nagpoproseso ng mga sertipiko ng kliyente. Kapag nagbe-verify ng DER-encoded digital signature, ide-decode ng NSS ang lagda sa isang fixed-size na buffer at ipinapasa ang buffer sa PKCS #11 module. Sa panahon ng karagdagang pagpoproseso, ang laki ay hindi wastong nasuri para sa mga lagda ng DSA at RSA-PSS, na humahantong sa pag-apaw ng buffer na inilalaan para sa istraktura ng VFYContextStr kung ang laki ng digital na lagda ay lumampas sa 16384 bits (2048 bytes ang inilalaan para sa buffer, ngunit hindi ito sinusuri na maaaring mas malaki ang lagda) ).
Ang code na naglalaman ng kahinaan ay maaaring masubaybayan noong 2003, ngunit hindi ito nagdulot ng banta hanggang sa isang refactoring na isinagawa noong 2012. Noong 2017, ang parehong pagkakamali ay ginawa kapag nagpapatupad ng suporta sa RSA-PSS. Upang magsagawa ng isang pag-atake, hindi kinakailangan ang pagbuo ng masinsinang mapagkukunan ng ilang mga susi upang makuha ang kinakailangang data, dahil ang overflow ay nangyayari sa yugto bago suriin ang kawastuhan ng digital na lagda. Ang bahagi ng data na lumalampas sa mga hangganan ay isinulat sa isang lugar ng memorya na naglalaman ng mga pointer sa mga function, na pinapasimple ang paglikha ng mga nagtatrabaho na pagsasamantala.
Natuklasan ng mga mananaliksik mula sa Google Project Zero ang kahinaan habang nag-eeksperimento sa mga bagong paraan ng pagsusubok at ito ay isang magandang pagpapakita kung paano maaaring hindi matukoy ang mga walang kabuluhang kahinaan sa loob ng mahabang panahon sa isang malawak na nasubok na kilalang proyekto:
- Ang NSS code ay pinananatili ng isang may karanasan na security team gamit ang makabagong pagsubok at mga diskarte sa pagsusuri ng error. Mayroong ilang mga programa sa lugar upang magbayad ng makabuluhang mga gantimpala para sa pagtukoy ng mga kahinaan sa NSS.
- Ang NSS ay isa sa mga unang proyekto na sumali sa oss-fuzz initiative ng Google at nasubok din sa libFuzzer-based fuzz testing system ng Mozilla.
- Ang code ng library ay maraming beses na nasuri sa iba't ibang static analyzer, kabilang ang pagsubaybay ng serbisyo ng Coverity mula noong 2008.
- Hanggang 2015, ginamit ang NSS sa Google Chrome at independyenteng na-verify ng Google team nang hiwalay sa Mozilla (mula noong 2015, lumipat ang Chrome sa BoringSSL, ngunit nananatili ang suporta para sa NSS-based na port).
Ang mga pangunahing problema dahil sa kung saan ang problema ay nanatiling hindi natukoy sa loob ng mahabang panahon:
- Ang NSS modular library at fuzzing testing ay isinagawa hindi bilang isang buo, ngunit sa antas ng mga indibidwal na bahagi. Halimbawa, ang code para sa pag-decode ng DER at pagpoproseso ng mga sertipiko ay hiwalay na nasuri - sa panahon ng fuzzing, maaaring makakuha ng isang sertipiko na hahantong sa pagpapakita ng kahinaan na pinag-uusapan, ngunit ang pagsusuri nito ay hindi umabot sa verification code at ang problema ay hindi ihayag ang sarili.
- Sa panahon ng fuzzing testing, ang mga mahigpit na paghihigpit ay itinakda sa laki ng output (10000 bytes) sa kawalan ng mga katulad na paghihigpit sa NSS (maraming istruktura sa normal na mode ang maaaring magkaroon ng sukat na higit sa 10000 bytes, kaya higit pang data ng input ang kinakailangan upang matukoy ang mga problema) . Para sa buong pag-verify, ang limitasyon ay dapat na 224-1 byte (16 MB), na tumutugma sa maximum na laki ng certificate na pinapayagan sa TLS.
- Maling kuru-kuro tungkol sa saklaw ng code sa pagsubok ng fuzz. Ang vulnerable code ay aktibong nasubok, ngunit gumagamit ng mga fuzzer na hindi nakabuo ng kinakailangang data ng input. Halimbawa, gumamit ang fuzzer tls_server_target ng paunang natukoy na hanay ng mga ready-made na certificate, na nilimitahan ang pagsuri ng code sa pag-verify ng certificate sa mga TLS na mensahe at pagbabago sa estado ng protocol.
Pinagmulan: opennet.ru