OpenSSL 3.x: инвентаризируем библиотеку в контейнерных образах до выхода патча

В прошлый вторник команда OpenSSL сделала необычный анонс: 1 ноября выйдет патч, закрывающий критическую уязвимость в OpenSSL версии 3.x. Деталей - никаких. Только: «3.0.0 - 3.0.6, критично, готовьтесь». CVE-номера ещё не опубликованы, эксплойтов никто не видел, но само слово «критично» от мейнтейнеров OpenSSL - это серьёзно. Последний раз они так делали с Heartbleed, и тогда было весело.

У нас сразу возник практический вопрос: а у клиентов вообще есть OpenSSL 3.x в инфраструктуре? И где именно?

Почему вопрос не такой тривиальный, как кажется

Если спросить у системного администратора «у вас стоит OpenSSL 3?», ответ обычно будет «нет, у нас Ubuntu 20.04, там 1.1.1». И технически это правда - на хосте будет OpenSSL 1.1.1. Но в 2022 году инфраструктура - это не только то, что стоит на хосте.

Контейнеры - это отдельная история. Образ на базе Ubuntu 22.04 или Fedora 36 уже тянет OpenSSL 3.0. Debian bookworm - тоже. Если разработчики берут свежий базовый образ без фиксации тега, они вполне могут получить OpenSSL 3.x внутри контейнера при том, что на хосте стоит 1.1.1.

Это первое, что нас беспокоит: расхождение между версией на хосте и версией внутри контейнерного окружения.

Что мы делаем прямо сейчас

Мы начали инвентаризацию по нескольким клиентам одновременно. Подход простой, но требует аккуратности.

На хостах - проверка через пакетный менеджер плюс поиск по файловой системе:

# RPM-based (РЕД ОС, Astra Linux с rpm-слоем)
rpm -qa | grep openssl

# Debian-based (Astra Linux SE 1.7/2.x, Ubuntu)
dpkg -l | grep openssl

# Прямой поиск библиотек - ловит то, что поставлено вне пакетного менеджера
find /usr /lib /lib64 -name 'libssl.so*' -o -name 'libcrypto.so*' 2>/dev/null

На практике на большинстве серверов под Astra Linux SE 1.7 и РЕД ОС 7.3 сидит OpenSSL 1.1.1. Версии 3.x на хостах у проверенных клиентов нет ни у одного - дистрибутивы со стабильными релизами её не тянут.

В контейнерных образах - вот здесь интереснее. Мы используем Syft, о котором писали неделю назад в контексте SBOM. Он умеет сканировать OCI-образы без их запуска:

# Сканируем образ напрямую из registry или локального daemon
syft registry:yourrepo/yourapp:latest -o table | grep -i openssl

# Или из архива образа
docker save yourapp:latest | syft - -o table | grep -i openssl

Syft разбирает слои OCI-образа и видит OpenSSL независимо от того, как он попал в образ - через apt, dnf или даже ручной установкой. Это важно: в production-образах иногда встречается openssl, собранный из исходников и положенный в /usr/local - он невидим для пакетного менеджера, но Syft его поймает.

Что нашли

По контейнерным образам картина интереснее, чем по хостам. Несколько команд разработки используют базовые образы типа python:3.10-slim или node:18-slim - а это Debian bookworm, и там OpenSSL 3.0. Разработчики об этом не думали: берут официальный образ из Docker Hub, всё работает, OpenSSL внутри - это не их забота.

Ещё одна точка - образы, собранные на CI по тегу latest. Полгода назад ubuntu:latest указывал на 20.04 с OpenSSL 1.1.1, сейчас указывает на 22.04 с OpenSSL 3.0. Если в Dockerfile написано FROM ubuntu:latest без фиксации дайджеста - версия библиотеки внутри образа могла тихо смениться при очередном пересборе.

Для отечественных дистрибутивов ситуация более предсказуемая: образы на базе РЕД ОС 7.3 и Astra Linux в Docker Hub или Gitverse тянут OpenSSL 1.1.1 из штатных репозиториев. Там 3.x нет.

Что делаем дальше

Инвентаризация - это только первый шаг. Пока у нас список образов с OpenSSL 3.x и список хостов, на которых они работают. Патч выйдет 1 ноября - примерно через четыре недели.

Наши следующие шаги до выхода патча:

• Зафиксировать базовые образы по дайджестам для образов, где нашли OpenSSL 3.x - чтобы понимать, что именно обновится после патча.
• Договориться с командами разработки о процедуре пересборки образов после выхода патча - кто, когда, в каком порядке.
• Проверить, не используются ли в образах кастомные сборки OpenSSL из исходников - эти патч от вендора не закроет, их придётся пересобирать вручную.

Пока деталей CVE нет, сложно оценить реальный риск. Heartbleed был катастрофой потому, что затронул практически всё и имел тривиальный эксплойт. Может выйти что-то менее страшное - но готовиться лучше заранее.

По результатам инвентаризации мы знаем, где у клиентов живёт OpenSSL 3.x. Это уже не плохо для начала. Патч выйдет - будем знать, что обновлять в первую очередь.

Аудит защищённости включает в том числе именно такую работу: не ждать пока CVE опубликована и уже есть эксплойт, а понимать поверхность атаки заранее.