CVE-2022-3602
OpenSSL 3.0: ошибка проверки адреса в сертификате
OpenSSL 3.0.0–3.0.6 мог повредить память при проверке особого адреса электронной почты в сертификате. Проверьте приложения, использующие эту библиотеку, и обновите их: сервер и клиент затронуты при разных условиях.
Кому нужно проверить
Администраторам HTTPS-клиентов, интеграций и серверов с проверкой клиентских сертификатов, а также разработчикам приложений на OpenSSL 3.0. Проверять нужно используемую библиотеку каждого приложения, включая контейнеры. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Сертификат — электронное удостоверение участника защищённого соединения. Он может содержать адрес электронной почты и ограничения допустимых имён. При обработке специально подготовленного адреса OpenSSL мог записать четыре байта за границу участка памяти в стеке — области временных данных функции. Производитель описывает падение приложения и потенциальное удалённое выполнение кода. Защитные механизмы платформ могут затруднять второе последствие. Обычное наличие HTTPS на сайте не доказывает применимость серверного сценария: существенна проверка клиентских сертификатов. Указанное в advisory отсутствие известных эксплуатаций относится к 1 ноября 2022 года, а не к сегодняшней ситуации.
Затронутые версии
OpenSSL 3.0.0–3.0.6 включительно. Ошибка находится в проверке ограничений имён сертификата X.509 и возникает после проверки подписей цепочки. Требуется либо подпись вредоносного сертификата центром сертификации, либо продолжение проверки приложением после неудачного построения цепочки к доверенному издателю. Для TLS-клиента рассматривается подключение к вредоносному серверу; для TLS-сервера — запрос клиентского сертификата и подключение вредоносного клиента. OpenSSL 1.1.1 и 1.0.2 этой конкретной ошибкой не затронуты, что не означает их общую безопасность или поддержку.
Исправленные версии
Первое исправление ветки 3.0 — OpenSSL 3.0.7. Сегодня выбирайте поддерживаемое исправленное обновление поставщика ОС или приложения, а не исторический минимум. Поставщик может перенести патч в старую пакетную версию. Для программы со встроенной библиотекой обновление системной команды openssl недостаточно: нужна обновлённая сборка самой программы.
Что сделать
- 1Составьте список приложений, использующих OpenSSL 3.0, и установите происхождение библиотек: пакет ОС, контейнер, встроенная или статически связанная копия. Сопоставьте пакет с уведомлением поставщика по CVE-2022-3602. Не делайте вывод обо всём сервере по одной команде openssl.
- 2Для клиентов проверьте, с какими внешними сервисами они соединяются. Для серверов уточните, запрашивают ли они клиентские сертификаты. Разработчику нужно проверить, не продолжает ли приложение проверку сертификата после ошибки доверия. Не отключайте проверку TLS: это создаёт самостоятельный риск подмены сервера.
- 3До обновления при необходимости ограничьте затронутые внешние соединения или доступ к сервису доверенным кругом. Это организационное уменьшение поверхности риска, не исправление OpenSSL. Отключать клиентские сертификаты без замены механизма входа нельзя: можно убрать важную проверку доступа.
- 4Сохраните настройки доверия и резервную копию приложения, предусмотрев защищённое хранение ключей. На тестовой среде обновите пакет или образ и проверьте обычные исходящие HTTPS-запросы, взаимную проверку сертификатов и интеграции. Повреждённые сертификаты для этой проверки не нужны.
- 5Разверните исправление и перезапустите использующие библиотеку процессы; статически связанные программы пересоберите. Подготовьте план восстановления образа и настроек. Если откат возвращает уязвимую библиотеку, сохраняйте ограничения доступа и согласуйте дальнейшее исправление.
- 6Подтвердите, что каждый работающий процесс использует исправленную сборку, а не только обновлённый файл на диске. Проверьте штатные соединения и журналы аварий. Дампы памяти храните закрыто: они могут содержать секреты. При признаках компрометации обновление дополняют расследованием и восстановлением доверия к системе.
Два пути к проверке недоверенного сертификата
Клиент получает сертификат сервера при исходящем соединении. Затронутый OpenSSL ошибается при обработке ограничения адреса электронной почты.
- 1Клиент получает сертификат сервера при исходящем соединении.
- 2Сервер получает сертификат клиента, если запрашивает такую проверку.
- 3В обоих случаях важны подписи цепочки и правила доверия приложения.
- 4Затронутый OpenSSL ошибается при обработке ограничения адреса электронной почты.
Примеры конфигурации и проверки
openssl versionДля терминала Linux/macOS с установленной командой openssl. Выполняйте без sudo в проверяемом окружении. Ожидается название реализации и версия; если выведено LibreSSL, это не номер OpenSSL 3.0 и сравнивать их напрямую нельзя. Команда не устанавливает соединение и ничего не меняет, откат не нужен. Она проверяет только выбранный инструмент и не перечисляет встроенные библиотеки других программ, уже загруженные копии и backport-патчи.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.