У наборы крыптаграфічных бібліятэк NSS (Network Security Services), якія развіваюцца кампаніяй Mozilla, выяўлена крытычная ўразлівасць (CVE-2021-43527), якая можа прывесці да выканання кода зламысніка пры апрацоўцы лічбавых подпісаў DSA або RSA-PSS, зададзеных з выкарыстаннем метаду кадавання DER ( Distinguished Encoding Rules). Праблема, якой прысвоена кодавае імя BigSig, ухілена ў выпусках NSS 3.73 і NSS ESR 3.68.1. Абнаўленні пакетаў у дыстрыбутывах даступныя для Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Пакуль недаступныя абнаўленні для Fedora.
Праблема праяўляецца ў дадатках, якія выкарыстоўваюць NSS для апрацоўкі лічбавых подпісаў CMS, S/MIME, PKCS #7 і PKCS #12, або пры верыфікацыі сертыфікатаў у рэалізацыях TLS, X.509, OCSP і CRL. Уразлівасць можа ўсплыць у розных кліенцкіх і серверных прыкладаннях з падтрымкай TLS, DTLS і S/MIME, паштовых кліентах і PDF-праглядшчыках, якія выкарыстоўваюць NSS-выклік CERT_VerifyCertificate() для праверкі лічбавых подпісаў.
У якасці прыкладу ўразлівых дадаткаў згадваюцца LibreOffice, Evolution і Evince. Патэнцыйна праблема таксама можа закранаць такія праекты, як Pidgin, Apache OpenOffice, Suricata, Curl, Сhrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss для http-сервера Apache, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Пры гэтым уразлівасць не выяўляецца ў Firefox, Thunderbird і Tor Browser, у якіх для верыфікацыі выкарыстоўваецца асобная бібліятэка mozilla::pkix, якая таксама ўваходзіць у склад NSS. Праблеме не схільныя і браўзэры на аснове Chromium (калі яны спецыяльна не сабраны c NSS), якія выкарыстоўвалі NSS да 2015 года, але затым былі перакладзены на BoringSSL.
Уразлівасць выклікана памылкай у кодзе праверкі верыфікацыі сертыфікатаў у функцыі vfy_CreateContext з файла secvfy.c. Памылка праяўляецца як пры чытанні кліентам сертыфіката з сервера, так і пры апрацоўцы серверам сертыфікатаў кліентаў. У працэсе праверкі лічбавага подпісу, закадаваным метадам DER, NSS дэкадуе подпіс у буфер, які мае фіксаваны памер, і перадае дадзены буфер у модуль PKCS #11. Пры далейшай апрацоўцы, для подпісаў DSA і RSA-PSS некарэктна правяраецца памер, што прыводзіць да перапаўнення буфера, выдзеленага пад структуру VFYContextStr, калі памер лічбавага подпісу перавышае 16384 біт (пад буфер вылучаецца 2048 байт, але не правяраецца, што подпіс можа быць большага памеру ).
Код, які змяшчае ўразлівасць, прасочваецца з 2003 года, але ён не ўяўляў пагрозы да рэфактарынгу, праведзенага ў 2012 годзе. У 2017 годзе пры рэалізацыі падтрымкі RSA-PSS была дапушчана тая ж памылка. Для здзяйснення нападу не патрабуецца рэсурсаёмістая генерацыя вызначаных ключоў для атрымання патрэбных дадзеных, бо перапаўненне адбываецца на стадыі да праверкі карэктнасці лічбавага подпісу. Якая выходзіць за межы частка дадзеных запісваецца ў вобласць памяці, утрымоўвальную паказальнікі на функцыі, што спрашчае стварэнне працоўных эксплоітаў.
Уразлівасць была выяўлена даследнікамі з Google Project Zero падчас эксперыментаў з новымі метадамі fuzzing-тэставанні і з'яўляецца добрай дэманстрацыі таго, як у шырока пратэставаным вядомым праекце могуць працяглы час заставацца незаўважанымі трывіяльныя ўразлівасці:
- Код NSS суправаджаецца доследнай камандай, якая адказвае за бяспеку, якая прымяняе сучасныя метады тэсціравання і аналізу памылак. Дзейнічае некалькі праграм па выплаце істотных узнагарод за выяўленне ўразлівасцяў у NSS.
- NSS быў адным з першых праектаў якія падключыліся ў ініцыятыве Google oss-fuzz і таксама правяраўся ў якая развіваецца Mozilla сістэме fuzzing-тэставанні на базе libFuzzer.
- Код бібліятэкі шматразова правяраўся ў розных статычных аналізатарах, у тым ліку з 2008 года адсочваўся сервісам Coverity.
- Да 2015 года NSS выкарыстоўваўся ў Google Chrome і незалежна ад Mozilla правяраўся камандай Google (з 2015 года Chrome перайшоў на BoringSSL, але падтрымка порта на базе NSS захоўваецца).
Асноўныя праблемы, з-за якіх праблема доўгі час заставалася незаўважанай:
- NSS модульная бібліятэка і fuzzing-тэставанне праводзілася не ў цэлым, а на ўзроўні асобных кампанентаў. Напрыклад, асобна правяраўся код дэкадавання DER і апрацоўкі сертыфікатаў у ходзе fuzzing-а цалкам мог быць атрыманы сертыфікат, які прыводзіць да праявы разгляданай уразлівасці, але яго праверка не даходзіла да кода верыфікацыі і праблема не выяўляла сябе.
- Пры fuzzing-тэставанні задаваліся цвёрдыя абмежаванні на памер высновы (10000 байт) пры адсутнасці падобных абмежаванняў у NSS (шматлікія структуры ў штатным рэжыме маглі мець памер больш 10000 байт, таму для выяўлення праблем патрабаваўся большы аб'ём уваходных дадзеных). Для паўнавартаснай праверкі ліміт павінен быў быць 224/1 байт (16 МБ), што адпавядае максімальнаму памеру сертыфіката, дапушчальнага ў TLS.
- Няслушнае ўяўленне аб ахопе кода fuzzing-тэставаннем. Уразлівы код актыўна тэставаўся, але з выкарыстаннем fuzzer-аў, не здольных згенераваць неабходныя ўваходныя дадзеныя. Напрыклад, fuzzer tls_server_target выкарыстоўваў наканаваны набор гатовых сертыфікатаў, што абмяжоўвала праверку кода верыфікацыі сертыфіката толькі TLS-паведамленнямі і зменамі стану пратаколу.
Крыніца: opennet.ru