CVE-2026-14457 в Ubuntu: отказ в обслуживании OpenSSL при RPK и защита

CVE: CVE-2026-14457
Продукт: Ubuntu
Дата публикации: 25.08.2026
Критичность: HIGH
CVSS: 7.5 (3.1)
EPSS: 0,98%; процентиль 59,32%
CISA KEV: нет подтверждения в каталоге CISA KEV

Краткое описание​

Уязвимость в OpenSSL позволяет удалённому хосту вызвать сбой приложения через NULL-указатель при использовании Raw Public Keys без сертификата. Для администраторов Ubuntu это означает риск простоя TLS-сервисов, если конфигурация не соответствует рекомендациям. Статья разбирает механику ошибки, затронутые версии пакетов и способы проверки исправления.

Основные характеристики​

Риск заключается в возможности удалённого отказа в обслуживании (DoS) для сервисов, использующих OpenSSL с конфигурацией Raw Public Keys (RPK) без привязанного сертификата. Атака не приводит к утечке данных или выполнению кода, но вызывает аварийное завершение процесса.

• Тип ошибки: CWE-476 (NULL Pointer Dereference). Сбой происходит при обращении к памяти, где объект не был инициализирован.
  
• CVSS 3.1: 7.5 (HIGH). Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Высокая оценка обусловлена сетевым вектором и отсутствием требований к правам доступа.
  
• Условия атаки: Атакующий не нуждается в учётных данных. Достаточно отправить TLS-запрос с определённым расширением к серверу с уязвимой конфигурацией.
  
• Эксплуатация: Публичные данные о массовой эксплуатации отсутствуют. EPSS составляет 0,98% (процентиль 59,32%), что указывает на умеренную вероятность эксплуатации в ближайшие 30 дней.
  
• Влияние на FIPS: Модули FIPS не затронуты, так как реализация протокола SSL находится за пределами границы FIPS-модуля.
  

Какие продукты и версии затронуты​

В Ubuntu уязвимость затрагивает несколько пакетов, в зависимости от версии системы и типа подписки. Основная проблема связана с пакетом openssl в Ubuntu 26.04 LTS, где исправление доступно без подписки.

• Ubuntu 26.04 LTS (resolute): Пакет openssl версии 3.5.5-1ubuntu3.4 и ниже. Затронуты бинарные пакеты libssl3t64, openssl и openssl-provider-legacy. Исправление включено в версию 3.5.5-1ubuntu3.4.
  
• Ubuntu Pro 16.04 LTS (xenial): Пакет nodejs версии 4.2.6~dfsg-1ubuntu4.2+esm3. Затронуты nodejs и nodejs-legacy.
  
• Ubuntu Pro 18.04 LTS (bionic): Пакет nodejs версии 8.10.0~dfsg-2ubuntu0.4+esm6.
  
• Ubuntu Pro FIPS (22.04/24.04): Пакет openssl-fips в версиях 3.0.5-0ubuntu0.1+Fips2.1, 3.0.5-0ubuntu0.2+Fips1 и 3.0.13-0ubuntu3.12+Fips1. Затронут модуль openssl-fips-module-3.
  
• Ubuntu 26.04 LTS (resolute): Пакеты edk2 и edk2-hwe также указаны в базе данных как затронутые, что может быть связано с зависимостями или ошибкой классификации в OSV, но основной фокус — на OpenSSL.
  

Причина уязвимости​

Причина уязвимости кроется в обработке TLS-расширения signature_algorithms_cert в конфигурациях, где включены Raw Public Keys (RPK) согласно RFC 7250, но локально настроен только приватный ключ без соответствующего сертификата.

В документации OpenSSL есть комментарий, намекающий на поддержку таких конфигураций, однако фактическая реализация не обрабатывает случай, когда сертификат отсутствует. Когда удалённый хост запрашивает RPK и одновременно отправляет расширение signature_algorithms_cert, код пытается обратиться к структуре сертификата, которая не была инициализирована (NULL-указатель). Это приводит к аварийному завершению процесса (segfault).

Рекомендуемая практика — всегда настраивать сертификат (даже самоподписанный) вместе с ключом. В этом случае расширение обрабатывается корректно даже в уязвимых версиях, а клиенты, не поддерживающие RPK, могут завершить соединение через верификацию сертификата.

Как работает атака​

Атакующий взаимодействует с TLS-сервером или клиентом, настроенным на использование RPK без сертификата. Во время рукопожатия TLS атакующий отправляет ClientHello (или ServerHello, в зависимости от роли) с двумя ключевыми элементами: запросом на использование Raw Public Keys и включённым расширением signature_algorithms_cert.

Обычно это расширение опускается, когда используются RPK, но его наличие заставляет OpenSSL перейти в ветку кода, предназначенную для выбора алгоритма подписи сертификата. Поскольку сертификат не настроен, указатель на него равен NULL. Функция, обрабатывающая выбор алгоритма, пытается прочитать данные из этого указателя, что вызывает исключение и падение приложения.

Важно, что атака не требует аутентификации. Достаточно установить TCP-соединение и отправить TLS-запрос. Сервер не успевает обработать данные, как процесс завершается. Это делает уязвимость идеальной для атак на отказ в обслуживании (DoS) против публичных сервисов.

Условия успешной эксплуатации​

Для успешной эксплуатации уязвимости необходимо соблюдение следующих условий:

• Конфигурация RPK: Сервис должен использовать OpenSSL с включённой поддержкой Raw Public Keys (RFC 7250).
  
• Отсутствие сертификата: В конфигурации должен быть указан только приватный ключ, без привязанного X.509 сертификата. Если сертификат настроен, уязвимость не проявляется.
  
• Уязвимая версия: Используется версия OpenSSL (или пакет, содержащий её, например nodejs), в которой отсутствует исправление.
  
• Сетевой доступ: Атакующий должен иметь возможность установить TLS-соединение с целевым хостом.
  

Возможный сценарий атаки​

Злоумышленник настраивает TLS-клиент для отправки нестандартного запроса к сервису, использующему RPK. В запросе включается флаг для RPK и добавляется расширение signature_algorithms_cert с валидными значениями алгоритмов.

Когда сервер получает этот запрос, он пытается обработать расширение. Из-за отсутствия сертификата в локальной конфигурации происходит обращение по NULL-указателю. Процесс сервера аварийно завершается. Если сервис не перезапускается автоматически, он становится недоступным.

Повторение запроса позволяет поддерживать состояние DoS. Для администратора это выглядит как внезапное падение TLS-сервиса без явных признаков атаки в логах приложения, кроме записи о segfault или аварийном завершении.

Есть ли публичный эксплойт​

На момент публикации данных публичный эксплойт в виде готового PoC или кода для массовой атаки не зафиксирован. В базе данных CISA KEV уязвимость не числится как активно эксплуатируемая.

Техническое описание атаки достаточно просто для реализации. Любой разработчик может написать скрипт на Python или C, использующий библиотеку OpenSSL, для отправки соответствующего TLS-запроса. Отсутствие публичного PoC не означает, что атакующие не могут эксплуатировать уязвимость самостоятельно.

EPSS 0,98% указывает на низкую, но ненулевую вероятность эксплуатации в ближайший месяц.

Признаки эксплуатации​

Специфичные IOC (индикаторы компрометации) для этой уязвимости не опубликованы, так как атака не оставляет характерных следов в данных, кроме самого факта сбоя. Ниже приведены неспецифичные точки контроля, которые могут указывать на попытку эксплуатации:

• Аварийное завершение процесса: Записи в системном журнале (/var/log/syslog или journalctl) о segfault или аварийном завершении процесса, использующего OpenSSL.
  
• Аномальные TLS-запросы: В логах TLS-сервера (если они настроены на детальный логирование) могут присутствовать запросы с расширением signature_algorithms_cert в контексте RPK-сессий.
  
• Повторяющиеся сбои: Регулярные падения сервиса в моменты, когда к нему обращаются внешние хосты, без видимых причин на стороне приложения.
  

Как обнаружить атаку​

Обнаружение атаки затруднено из-за отсутствия специфичных сигнатур. Рекомендуется использовать следующие методы:

• Мониторинг стабильности: Настройка алертов на аварийное завершение процессов, использующих OpenSSL. Если сервис падает без причины, это может быть признаком эксплуатации.
  
• Анализ TLS-трафика: Если используется прокси или балансировщик нагрузки, можно анализировать TLS-запросы на наличие аномальных расширений. Однако это требует глубокой инспекции.
  
• Регулярное сканирование: Использование сканеров уязвимостей для проверки конфигураций TLS-сервисов. Некоторые сканеры могут проверять наличие RPK без сертификата.
  

Эти методы не гарантируют обнаружение атаки. Основной упор должен быть сделан на предотвращение (исправление и правильная конфигурация).

Как проверить свою версию​

Для проверки версии OpenSSL и статуса обновлений в Ubuntu используйте следующие команды. Замените <имя-пакета> на фактическое имя пакета (например, openssl или nodejs), если вы проверяете конкретный пакет.

# Проверка версии ОС
cat /etc/os-release

# Проверка версии ядра (для контекста)
uname -r

# Проверка доступных версий пакета и установленных обновлений
apt-cache policy openssl

# Проверка статуса безопасности системы
ubuntu-security-status

В выводе apt-cache policy обратите внимание на строку Candidate:. Если версия совпадает с исправленной (например, 3.5.5-1ubuntu3.4 для Ubuntu 26.04), система защищена. Если версия ниже, требуется обновление.

Исправление​

Основной способ устранения уязвимости — обновление пакетов до исправленных версий. Для Ubuntu 26.04 LTS обновление доступно без подписки.

• Ubuntu 26.04 LTS: Выполните sudo apt update && sudo apt upgrade для обновления пакета openssl до версии 3.5.5-1ubuntu3.4 и выше.
  
• Ubuntu Pro (16.04/18.04): Обновите пакет nodejs через esm-apps репозиторий. Убедитесь, что подписка активна и репозиторий настроен.
  
• Ubuntu Pro FIPS: Обновите пакет openssl-fips через соответствующий FIPS-репозиторий.
  

Дополнительно, если вы используете RPK, рассмотрите возможность настройки сертификата (даже самоподписанного) вместе с ключом. Это устранит уязвимость даже в старых версиях OpenSSL, так как код будет обрабатывать расширение корректно.

Временные меры защиты​

Если немедленное обновление невозможно, можно применить следующие временные меры:

• Настройка сертификата: Добавьте X.509 сертификат (самоподписанный или от CA) к приватному ключу в конфигурации OpenSSL. Это предотвратит обращение по NULL-указателю, так как код будет иметь валидный объект для работы.
  
• Отключение RPK: Если функциональность Raw Public Keys не критична, отключите её в конфигурации. Это полностью уберёт уязвимый код из пути выполнения.
  
• Ограничение доступа: Если возможно, ограничьте доступ к TLS-сервису только доверенными IP-адресами через firewall. Это снизит вероятность атаки со стороны случайных сканеров.
  

Эти меры не заменяют обновление, но снижают риск эксплуатации в краткосрочной перспективе.

Как проверить устранение уязвимости​

После обновления пакетов проверьте, что уязвимость устранена:

1. Проверка версии: Убедитесь, что установленная версия пакета соответствует исправленной. Используйте apt-cache policy openssl или аналогичную команду для других пакетов.
   
2. Тестирование: Если возможно, проведите тестовое TLS-рукопожатие с клиентом, который отправляет signature_algorithms_cert в контексте RPK. Сервер должен обработать запрос без сбоя.
   
3. Мониторинг: Наблюдайте за стабильностью сервиса в течение нескольких дней после обновления. Отсутствие аварийных завершений подтверждает эффективность исправления.
   

Не забудьте перезапустить сервисы, использующие OpenSSL, после обновления пакетов, чтобы изменения вступили в силу.

Вывод​

CVE-2026-14457 представляет собой риск отказа в обслуживании для сервисов, использующих OpenSSL с RPK без сертификата. Хотя уязвимость не позволяет атакующему получить доступ к данным или выполнить код, она может привести к простою критических TLS-сервисов.

Администраторам Ubuntu следует проверить конфигурации своих TLS-сервисов, убедиться в наличии сертификатов для RPK-ключей и обновить пакеты до исправленных версий. Для Ubuntu 26.04 LTS обновление доступно без подписки, что упрощает процесс устранения.

Официальные источники​

1. NVD — CVE-2026-14457
   
2. Ubuntu OSV — CVE-2026-14457
   
3. FIRST EPSS — CVE-2026-14457
   

История обновлений статьи​

• 29.08.2026 — Опубликована первая версия материала.