OpenSSL 3.0.7 вышел: CVE-2022-3786 и CVE-2022-3602 закрыты, все клиентские серверы обновлены за двое суток

1 ноября вышел OpenSSL 3.0.7. Две уязвимости - CVE-2022-3786 и CVE-2022-3602 - закрыты. Обе связаны с переполнением буфера при обработке сертификатов с Punycode-именами в расширении X.509 GeneralName. До выхода патча их анонсировали как критические - редчайший уровень для OpenSSL после Heartbleed. По факту, когда детали вышли, CVSS оказался в районе 7.5-8.x, и эксперты довольно быстро опустили статус до High. Эксплойт требует специально сформированного сертификата, который клиент должен попытаться верифицировать - сценарий рабочий, но не тривиальный.

Тем не менее две недели паники индустрия отработала честно. Мы в том числе.

Что мы готовили

Три недели назад мы проводили инвентаризацию OpenSSL 3.x по всей клиентской базе. Итог был предсказуемым: на хостах под Astra Linux SE 1.7 и РЕД ОС 7.3 OpenSSL 3.x практически отсутствует - эти дистрибутивы тянут 1.1.1 из штатных репозиториев, и менять это никто не собирался. Основная поверхность - контейнерные образы на базе Ubuntu 22.04, Debian bookworm/testing, свежих python: и node: из Docker Hub.

Именно там мы составили список того, что нужно обновить в первую очередь. К 1 ноября он уже лежал готовым: по каждому клиенту - перечень образов с OpenSSL 3.x, контейнеры на production, ответственные за пересборку.

Как шло обновление

Патч вышел в 13:00 UTC 1 ноября. К этому времени вендоры дистрибутивов уже несколько дней держали патч под NDA и готовили пакеты заранее - Ubuntu 22.04 получила обновлённый пакет практически одновременно с официальным анонсом OpenSSL.

Схема обновления по клиентам в managed-сопровождении была такая:

• Хосты - прямое обновление через пакетный менеджер там, где OpenSSL 3.x всё-таки присутствовал. Это оказалось быстрой историей: apt upgrade openssl, рестарт сервисов, которые держат библиотеку в памяти (в первую очередь nginx, stunnel, haproxy), проверка версии.

• Контейнерные образы - пересборка с обновлённым базовым образом. Вот здесь основная работа. Команды разработки были предупреждены заранее, pipeline-ы у большинства настроены, но дьявол в деталях: несколько образов собирались по тегу latest без фиксации дайджеста, и пришлось убеждаться, что пересборка реально тянет обновлённый базовый образ, а не закешированный слой недельной давности.

• Кастомные сборки - нашли два случая: OpenSSL, собранный из исходников в /usr/local для старого приложения. Пакетный менеджер его не видит, apt upgrade мимо. Здесь пересобирали вручную - скачали 3.0.7, собрали, положили на место. Без этого пункта инвентаризация с Syft была бы напрасной: именно она вытащила эти две инсталляции.

За сколько уложились

Два дня с хвостом. Основная масса хостов и контейнеров - в течение первых суток. Хвост - это как раз кастомные сборки и несколько клиентов, у которых пересборка образов требовала согласования с их внутренней командой разработки. Там мы выступали в роли «напоминальщика» и помогали убедиться, что обновлённый образ реально ушёл в production, а не завис в staging.

Финальный отчёт покрытия по каждому клиенту - простая таблица: хост/образ, версия OpenSSL до, версия после, дата обновления. Ничего сложного, но именно этого обычно и не хватает: подтверждения, что обновление дошло туда, куда должно, а не просто «мы запустили apt upgrade».

Что CVE оказался не таким страшным

Это надо зафиксировать честно. Индустрия готовилась к чему-то уровня Heartbleed - широкой поверхности, тривиальному эксплойту, немедленной утечке данных. Получили кое-что другое: уязвимость реальная, эксплуатируемая в специфических условиях (TLS-клиент, который верифицирует сертификат с Punycode в Subject Alternative Name от потенциально враждебного сервера), но без массового trivial exploit.

Это, впрочем, не значит, что паника была лишней. Объявление критического уровня за две недели до деталей - правильная практика: дать время подготовиться. И если бы CVE оказался действительно Heartbleed-уровня, а инвентаризации не было, - закрыть дыру за двое суток не вышло бы.

Что осталось

Несколько образов с кастомной сборкой OpenSSL теперь у нас на отдельном контроле. Это приложения, которые по разным причинам не могут просто переключиться на системный пакет, и для них обновление OpenSSL - ручная работа каждый раз. Мы зафиксировали это в карточках клиентов как отдельный пункт технического долга.

Ещё один вывод: инвентаризация с Syft, о которой писали месяц назад, - это не разовая история. Образы обновляются, в Dockerfile появляются новые базовые образы, разработчики добавляют зависимости. Список «где у нас OpenSSL 3.x» устаревает. Без регулярного сканирования к следующему CVE такого класса мы снова будем тратить несколько дней просто на понимание поверхности атаки, а не на закрытие.

Постараемся не допустить.