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

Беше идентифицирана критична уязвимост (CVE-2021-43527) в набора от криптографски библиотеки NSS (Услуги за мрежова сигурност), разработен от Mozilla, която може да доведе до изпълнение на код на атакуващ при обработка на цифрови подписи DSA или RSA-PSS, посочени с помощта на DER метод на кодиране (Отличителни правила за кодиране). Проблемът с кодово име 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, които използват отделна библиотека 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 и също беше тестван в системата за тестване на fuzz на Mozilla, базирана на libFuzzer.
• Кодът на библиотеката е проверяван многократно в различни статични анализатори, включително се наблюдава от услугата Coverity от 2008 г.
• До 2015 г. NSS се използваше в Google Chrome и беше независимо проверен от екипа на Google независимо от Mozilla (от 2015 г. Chrome премина към BoringSSL, но поддръжката за базирания на NSS порт остава).

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

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

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