У наборі криптографічних бібліотек 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 (якщо вони спеціально не зібрані з 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 був одним з перших проектів oss-fuzz, що підключилися в ініціативі Google, і також перевірявся в системі 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