Ubuntu не выпускает патч для 0day RCE в Linux уже три недели

Ubuntu не выпускает патч для 0day RCE в Linux уже три недели

На Hacker News обсуждают, почему Canonical почти три недели не выпускает патч для 0day RCE в ядре Linux. Разбираем риски для Ubuntu LTS и временные меры защиты.

Что известно о уязвимости и задержке с патчем

Что известно о уязвимости и задержке с патчем

Уязвимость типа 0day RCE в ядре Linux уже три недели не закрыта патчем в репозиториях Ubuntu. Для серверов на Ubuntu LTS это означает, что известный вектор атаки остаётся открытым, пока Canonical не соберёт и не выпустит обновлённый пакет ядра. Ниже разбираем, что говорит разработчик дистрибутива и как сообщество отреагировало на задержку.

Что говорит Canonical

Canonical не публиковала точных сроков выпуска патча. В таких случаях компания обычно ссылается на стандартный процесс проверки обновлений ядра: сборка, тестирование на поддерживаемых релизах, подготовка Ubuntu Security Notice (USN) и только потом публикация в репозитории security. Для администраторов это значит, что ждать официального объявления нужно в рассылке безопасности или на странице Ubuntu Security Notices.

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

bashКопировать
uname -r
apt list --installed | grep linux-image

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

bashКопировать
sudo ufw deny 445/tcp

Для критически важных систем стоит присмотреться к Ubuntu Livepatch — он позволяет накладывать некоторые исправления ядра без перезагрузки, но не для всех уязвимостей и не на всех выпусках LTS.

Реакция сообщества на Hacker News

На Hacker News задержку обсуждают резко. Пользователи отмечают, что другие дистрибутивы — Debian, Fedora, Arch — уже выпустили обновления или хотя бы временные обходные пути, в то время как Ubuntu LTS всё ещё ждёт официального патча. Основная претензия не к самому существованию уязвимости, а к отсутствию прозрачности: нет оценки времени, нет временного обхода, нет чёткого ответа, затронуты ли все поддерживаемые релизы или только некоторые.

Из практических советов, которые звучат в дискуссии:

• отключить уязвимый модуль ядра, если он не нужен, через /etc/modprobe.d/blacklist.conf;
• использовать AppArmor или SELinux для ограничения поверхности атаки;
• пересобрать ядро из основной ветки Linux, если навыки и инфраструктура позволяют;
• сегментировать сеть, чтобы уязвимый узел не имел прямого доступа извне.

Для домашних серверов, стоящих за NAT и не открытых в интернет, риск эксплуатации существенно ниже, но игнорировать уязвимость всё равно не стоит. Если машина выполняет роль шлюза, VPN-сервера или принимает загрузки от пользователей, стоит временно ограничить входящие соединения на уровне роутера или брандмауэра, пока Canonical не выпустит обновление.

Предсказуемость конфигураций здесь важнее скорости: лучше заранее знать, какие сервисы в вашей сети используют уязвимый код, и иметь план отката, чем ставить патч «на коленке» и ломать рабочую среду.

Как оценить риск для своей инфраструктуры

Как оценить риск для своей инфраструктуры

Оценка риска без инвентаризации — как попытка потушить пожар, не зная, где лежат клапана от газа. Прежде чем судить о степени угрозы, нужно точно знать, что у вас запущено.

Какие версии Ubuntu затронуты

Во-первых, версия дистрибутива и версия ядра — разные вещи. Ubuntu 22.04 LTS может работать на ядре 5.15, 6.5 или 6.8 в зависимости от даты установки и применённых обновлений.

Проверьте релиз системы:

bashКопировать
lsb_release -a

Посмотрите текущее ядро:

bashКопировать
uname -r

Установите, какие пакеты ядра установлены в системе:

bashКопировать
dpkg -l | grep -E 'linux-image|linux-headers'

С практической точки зрения, задержка Canonical означает, что даже LTS-релизы (22.04 Jammy, 20.04 Focal) остаются без официального исправления всё время, пока патч не выйдут. Промежуточные релизы тоже могут быть в зоне риска, но точный список зависит от конкретного CVE. Свериться с бюллетенями безопасности можно в материалах, которые мы публиковали ранее: Патч для 0day RCE в ядре Linux всё ещё не выпущен Ubuntu и Задержка патча Ubuntu для 0day RCE в Linux.

Если у вас смешанная инфраструктура, составьте таблицу хостов с версиями ядра. Без этого вы не поймёте, какой процент машин действительно уязвим, а какой уже защищён сторонними обновлениями или временными мерами.

Признаки эксплуатации в логах

Патча нет, значит нужно мониторить поведение системы. Я не рекомендую ждать чего-то конкретного вроде «строки эксплойта в syslog» — большинство 0day в ядре не оставляют очевидных следов в обычных логах. Но есть косвенные признаки, которые стоит отслеживать.

Посмотрите сообщения ядра за последние несколько дней:

bashКопировать
journalctl -k --since "3 days ago"

Ищите записи с Call Trace, Kernel panic, Oops, BUG. Это не гарантия эксплуатации, но повод проверить машину вручную:

bashКопировать
journalctl -k --since "3 days ago" | grep -i -E 'call trace|panic|oops|bug'

Проверьте аутентификацию. Если уязвимость позволяет повышение привилегий, вы можете увидеть необычные сессии от имени root:

bashКопировать
grep -E 'Accepted|Failed|session opened' /var/log/auth.log | grep -v '^$'

Обратите внимание на загрузку модулей ядра. Злоумышленник может попытаться загрузить вредоносный модуль после эксплуатации:

bashКопировать
lsmod | grep -v '^Module'

Или посмотреть историю загрузок через журнал ядра:

bashКопировать
journalctl -k | grep -i 'module'

С точки зрения предсказуемости конфигураций, я бы рекомендовал включить auditd и отслеживать системные вызовы, связанные с работой с памятью и сетью, если вы подозреваете целевую атаку. Пример правила для аудита доступа к /dev/mem:

bashКопировать
auditctl -a exit,always -F arch=b64 -S openat -F path=/dev/mem

Но помните: без знания точного механизма уязвимости вы можете пропустить эксплуатацию. Поэтому основная защита сейчас — ограничение доступа к серверу, минимальный набор открытых портов и разделение сети. Подробнее об инструментах и практике можно почитать в отдельном материале: Skills for Real Engineers: Инструменты и практика.

Если мы посмотрим на ситуацию со стороны инженера, то задержка патча — это не повод паниковать, а повод проверить инвентаризацию и логи. Серверы не падают от одного дня без обновления, но они падают от отсутствия понимания, что именно у вас запущено.

Что делать до выхода официального обновления

Что делать до выхода официального обновления

Три недели без патча для критической уязвимости в ядре Linux — это долго. Для Ubuntu LTS ситуация особенно чувствительна: корпоративные клиенты и опытные администраторы рассчитывают на стабильность, а получают открытое окно для атаки, которое официальное обновление пока не закрывает. С практической точки зрения, до выхода фикса нужно сделать две вещи: снизить поверхность атаки и обнаружить попытку эксплуатации до того, как она увенчается успехом.

Во-первых, ограничьте сетевой доступ к уязвимым интерфейсам. Если уязвимость проявляется через сетевой стек, лишний трафик на сервере не нужен.

Временные ограничения доступа и сетевые экраны

На Ubuntu по умолчанию установлен UFW. Это удобно для быстрого ограничения доступа, но для сервера я предпочитаю писать правила в iptables или nftables — так конфигурация предсказуемее и не зависит от обёрток.

Пример базовой политики через UFW:

bashКопировать
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp
sudo ufw enable

Если сервер принимает только определённый трафик, откройте только нужные порты и только из доверенных сетей. Всё остальное — на запрет.

Для более тонкой фильтрации можно использовать nftables. Ниже пример, который блокирует входящие подключения, кроме подсети администраторов:

nftКопировать
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state established,related accept
        ip saddr 10.0.0.0/8 tcp dport 22 accept
        ip saddr 10.0.0.0/8 tcp dport 80 accept
        log prefix "nftables drop: "
    }
}

Если уязвимость связана с конкретным сетевым протоколом или портом, ограничьте доступ к нему на уровне брандмауэра, даже если сервис привязан к 0.0.0.0. Лучше вообще перевести сервис на localhost, если он не нужен внешним клиентам:

bashКопировать
# Перед изменением убедитесь, что приложение корректно работает с 127.0.0.1
sudo sed -i 's/0\.0\.0\.0/127.0.0.1/' /etc/имя-приложения/конфиг.conf
sudo systemctl restart имя-приложения

Проверьте, что порт действительно закрыт для внешних адресов:

bashКопировать
sudo ss -tulpn | grep :80

Если вы не уверены, какой именно компонент ядра уязвим, посмотрите материалы о задержке патча: Задержка патча Ubuntu для 0day RCE в Linux и Ubuntu не выпустила патч для 0day RCE в ядре Linux.

Мониторинг и алерты на подозрительную активность

Ограничение доступа снижает вероятность эксплуатации, но не исключает её полностью. Если атакующий уже внутри сети или уязвимость проявляется локально, нужно видеть попытки эксплуатации в реальном времени.

На Ubuntu удобно использовать auditd — он в репозиториях и интегрируется с ядром. Ниже правило, которое фиксирует попытки загрузки модулей и выполнение привилегированных команд:

bashКопировать
# /etc/audit/rules.d/custom.rules
-w /usr/bin/systemctl -p x -k systemctl_exec
-w /sbin/insmod -p x -k module_load
-w /sbin/modprobe -p x -k module_load
-a always,exit -F arch=b64 -S execve -F uid=0 -k root_exec

После добавления правил перезагрузите аудит:

bashКопировать
sudo augenrules --load
sudo systemctl restart auditd

Просматривайте логи на наличие подозрительной активности:

bashКопировать
sudo ausearch -k module_load -i
sudo journalctl -k -p err --since "1 hour ago"

Для алертов я использую Prometheus с node_exporter и Alertmanager. Пример правила, которое срабатывает при необычной активности ядра:

yamlКопировать
groups:
- name: kernel_alerts
  rules:
  - alert: KernelOopsDetected
    expr: increase(node_uname_info{job="node"}[5m]) > 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Обнаружены изменения в информации о ядре на {{ $labels.instance }}"
      description: "Проверьте, не произошло ли перезагрузки ядра или ошибочной ситуации."

Если у вас уже есть стек мониторинга, добавьте алерт на рост количества сетевых соединений в состоянии SYN_RECV или на необычные исходящие подключения с сервера. Это поможет заметить попытку эксплуатации до того, как атакующий закрепится в системе.

Главное здесь — предсказуемость. Сервер должен вести себя так, как вы ожидаете. Любое отклонение от нормы — повод проверить, не идёт ли эксплуатация уязвимости. Если хотите углубиться в практику администрирования, посмотрите подборку инструментов: Skills for Real Engineers: Инструменты и практика.

Долгосрочные выводы для администрирования Ubuntu

Долгосрочные выводы для администрирования Ubuntu

Когда патч для критической уязвимости в ядре задерживается на три недели, вопрос перестаёт быть только про Canonical. Он становится про то, как вы сами организуете обновления на своих серверах. Ubuntu LTS не означает «установил и забыл» — это просто обещание поддержки на пять лет, а не гарантия, что патч прилетит в тот же день, что и upstream. Эту задержку уже разбирают на Hacker News и в наших материалах: Задержка патча Ubuntu для 0day RCE в Linux.

Почему важно отслеживать CVE и патчи

CVE — это не каталог для любопытных, а система раннего предупреждения. Если вы не знаете, что ядро на ваших серверах уязвимо, вы не сможете принять решение: закрыть порт, ограничить доступ или перенести нагрузку на резервный узел.

На практике отслеживание выглядит так. Раз в неделю проверяйте вывод ubuntu-security-status — он покажет, какие пакеты имеют неисправленные уязвимости:

bashКопировать
ubuntu-security-status

Если в списке появился linux-image с пометкой о неисправленной уязвимости, значит, патч ещё не дошёл до вашего репозитория. В этот момент стоит заглянуть в безопасность Ubuntu или в список CVE на MITRE, чтобы понять масштаб проблемы.

Для автоматизации можно включить unattended-upgrades, но не слепо. Пример конфига /etc/apt/apt.conf.d/50unattended-upgrades:

confКопировать
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}:${distro_codename}-updates";
};

Это заставит систему тянуть только обновления безопасности и обновления пакетов, но не новые версии дистрибутива. Проверьте работу в сухом режиме:

bashКопировать
unattended-upgrades --dry-run --debug

Отслеживание CVE нужно не для того, чтобы бежать патчить каждую уязвимость в день выхода. Оно нужно для того, чтобы вы знали, насколько подвержены риску, и могли спланировать окно обновления, а не гасить пожар в три часа ночи.

Построение предсказуемого процесса обновлений

Предсказуемость — это то, что отличает администрирование от тушения пожаров. Если обновления приходят неожиданно, вы получаете простой. Если они запланированы, вы контролируете риск.

Практический пример из моей лаборатории. У меня три ноды на Proxmox, которые названы в честь персонажей советских мультфильмов: Винни-Пух, Пятачок, Сова. Сначала я обновляю Винни-Пуха — самую старую и наименее критичную ноду. Дождался, пока система проработала сутки без алертов в Prometheus, только потом качу обновление на остальные.

Процесс выглядит так:

1. Подготовьте тестовую ноду или staging-окружение.
2. Установите обновления и перезагрузите, если требуется.
3. Проверьте, какие сервисы нуждаются в перезапуске:

bashКопировать
needrestart

4. Убедитесь, что мониторинг молчит. Если Grafana или Alertmanager не показывают аномалий, катите обновление на продакшен.

Для автоматизации настройки (не деплоя, а именно конфигурации) я использую Ansible. Пример задачи, которая включает автоматическое обновление безопасности:

yamlКопировать
- name: Enable unattended upgrades
  ansible.builtin.copy:
    dest: /etc/apt/apt.conf.d/20auto-upgrades
    content: |
      APT::Periodic::Update-Package-Lists "1";
      APT::Periodic::Unattended-Upgrade "1";

Важный момент: обновления ядра требуют перезагрузки. Планируйте окно перезагрузки заранее, а не когда сервер уже упал. Проверьте, когда последний раз перезагружался сервер:

bashКопировать
uptime -s

Если вывод показывает месяц работы без перезагрузки, а ядро имеет неисправленную уязвимость — у вас есть время спланировать окно, а не экстренно ребутить в пятницу вечером.

Отслеживание CVE и предсказуемый процесс обновлений — это два инструмента, которые делают Ubuntu LTS по-настоящему безопасной. Без них вы просто надеетесь, что Canonical выпустит патч вовремя. С ними вы знаете, что делать, даже если патч задержится. Подробнее о текущей ситуации с патчем можно почитать в нашем материале: Патч для 0day RCE в ядре Linux всё ещё не выпущен Ubuntu.

Часто задаваемые вопросы

Безопасно ли держать сервер на Ubuntu LTS в интернете без патча?

Зависит от того, какой трафик принимает сервер. Если он доступен извне и обрабатывает недоверенные пакеты, риск эксплуатации выше, чем для узлов за брандмауэром. Пока патча нет, имеет смысл ограничить доступ к уязвимым интерфейсам на уровне сети и мониторить объявления Canonical. Это не устраняет уязвимость, но снижает поверхность атаки.

Поможет ли Ubuntu Livepatch закрыть уязвимость без перезагрузки?

Livepatch накладывает некоторые исправления ядра без перезагрузки, но не для всех уязвимостей и не на всех выпусках LTS. Нужно проверить, поддерживается ли ваша версия ядра и дистрибутива. Если поддержки нет, придётся ждать официального пакета ядра или применять временные сетевые ограничения.

Какие временные меры защиты можно применить прямо сейчас?

Сначала убедитесь, какая версия ядра установлена: uname -r. Затем ограничьте доступ к уязвимому порту на границе сети, например: sudo ufw deny 445/tcp. Это временная мера, она не заменяет патч, но даёт время дождаться официального обновления. После выхода USN обязательно обновите ядро и перезагрузите сервер.

Как понять, что сервер уже подвергся эксплуатации?

Ищите аномальные процессы, необычные сетевые соединения и записи в journald и dmesg. Уязвимость типа RCE в ядре может оставлять следы в системных логах, поэтому проверьте их на предмет подозрительной активности. Если есть сомнения, изолируйте сервер и проводите расследование перед восстановлением из бэкапа. Предсказуемость инфраструктуры начинается с чёткого понимания того, что происходит на узле.

Где отслеживать выпуск патча и как применить его?

Официальная информация публикуется в рассылке безопасности Ubuntu и на странице Ubuntu Security Notices. Как только USN появится, обновите пакет ядра: sudo apt update && sudo apt upgrade --only-upgrade linux-image-$(uname -r). После установки обязательно перезагрузите сервер, чтобы новое ядро вступило в силу. Без перезагрузки старый уязвимый код останется в памяти.