Уязвимост в 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, и също така беше тестван в развиваната система за fuzzing-тестиране на Mozilla, базирана на libFuzzer.
• Кодът на библиотеката многократно е проверяван в различни статични анализатори, включително е проследяван от Coverity от 2008 година.
• До 2015 година NSS се използваше в Google Chrome и независимо от Mozilla беше проверяван от екипа на Google (от 2015 година Chrome премина на BoringSSL, но поддръжката на порта на базата на NSS остава).

Основните проблеми, поради които проблема дълго време оставалася незабелязана:

• NSS е модулна библиотека и fuzzing-тестиране се провеждаше не в цялост, а на ниво отделни компоненти. Например, кодът за декодиране на DER и обработка на сертификати беше проверяван поотделно — по време на fuzzing-а може да е получен сертификат, който води до проявата на разглежданата уязвимост, но неговата проверка не достига до кода за верификация и проблемът не се открива.
• При fuzzing-тестиране бяха зададени строги ограничения на размера на изхода (10000 байта) при отсъствието на подобни ограничения в NSS (много структури в стандартен режим можеха да имат размер над 10000 байта, затова за откритие на проблеми беше необходим по-голям обем входни данни). За пълноценна проверка лимитът трябваше да е 224-1 байта (16 МБ), което отговаря на максималния размер на сертификата, допустим в TLS.
• Неправилно представяне на обхвата на кода, тестван с fuzzing. Уязвимият код бе активно тестван, но с използването на fuzzers, неспособни да генерират необходимите входни данни. Например, fuzzer tls_server_target използваше предварително определен набор от готови сертификати, което ограничи проверката на кода за верификация на сертификата само до TLS съобщения и промени в състоянието на протокола.

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