🥇Уязвимост в Mozilla NSS, позволяваща изпълнение на код при обработка на сертификати

В пакета криптографски библиотеки 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, Chrony, 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 (освен ако не са специално събрани с 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 MB), което съответства на максималния размер на сертификата, допустим в TLS.
Неправилно схващане за обхвата на кода, подложен на fuzzing тестове. Уязвимият код активно се тестваше, но с помощта на fuzzer-и, които не можеха да генерират необходимите входни данни. Например, fuzzer tls_server_target използваше предварително зададен набор от готови сертификати, което ограничавало проверката на кода за верификация на сертификата само до TLS съобщения и промени в състоянието на протокола.

Източник: opennet.ru