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

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

Уже почти три недели уязвимость в ядре Linux остаётся без патча в Ubuntu LTS. Разбираем риски для серверов и способы защиты до выхода обновления.

Что произошло с патчем для ядра Ubuntu

Что произошло с патчем для ядра Ubuntu

Уже почти три недели уязвимость в ядре Linux остаётся без патча в Ubuntu LTS. Для дистрибутива, который обычно выпускает обновления безопасности в течение нескольких дней, это аномалия. Если вы держите продакшен-серверы на Ubuntu 22.04 LTS или 20.04 LTS, ядро по-прежнему уязвимо, а ждать фикса приходится неделями.

Хронология инцидента и статус CVE

Информация об уязвимости появилась в публичных источниках примерно три недели назад. На момент написания статьи патч не попал ни в репозиторий ubuntu-security, ни в -proposed, ни в -updates. CVE-идентификатор, судя по открытым базам, либо ещё не присвоен, либо не отражён в общедоступном трекере Canonical. Я не буду называть выдуманный номер — проверяйте статус сами.

Посмотреть установленное ядро можно так:

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

Если версия совпадает с той, что указана в уязвимом наборе, сервер находится под угрозой. Отслеживать движение патча стоит в базе безопасности Ubuntu и в рассылке Ubuntu Security Notices. Как только USN выйдет, версия ядра в -security обновится, и достаточно будет выполнить:

bashКопировать
sudo apt update
sudo apt upgrade linux-image-generic
sudo reboot

Перезагрузка обязательна — ядро подгружается при старте, и без неё новый патч не вступит в силу.

Почему задержка критична для LTS-релизов

LTS-релиз позиционируется как стабильная платформа на пять лет, но стабильность не означает отсутствия угроз. Наоборот: чем дольше уязвимость висит без патча, тем выше вероятность, что exploit попадёт в публичный доступ и будет использован в массовых атаках. RCE в ядре — это не просто «упал сервис». Это возможность выполнить код с правами ядра, выйти из контейнера, повысить привилегии и получить полный контроль над хостом.

С практической точки зрения, задержка критична по трём причинам:

1. Контейнеризация не спасает. Если вы запускаете Docker на уязвимом хосте, злоумышленник, выполнивший код внутри контейнера, может использовать ядерную уязвимость для выхода на хост. Изоляция контейнера — это не граница безопасности на уровне ядра.
2. LTS используется на критичной инфраструктуре. Базы данных, файловые хранилища, шлюзы — всё это часто крутится на Ubuntu LTS именно из-за обещанной долгосрочной поддержки. Когда поддержка задерживается, риск ложится на бизнес.
3. Откат сложнее, чем обновление. Если вы уже применяли какие-то временные меры (например, меняли параметры ядра через sysctl), их нужно аккуратно откатить после выхода патча, иначе получите конфликт конфигураций.

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

Пока патча нет, можно снизить поверхность атаки. Например, отключить непривилегированные пользовательские пространства имён, если они не нужны вашим приложениям:

bashКопировать
sysctl -w kernel.unprivileged_userns_clone=0

Чтобы настройка пережила перезагрузку, добавьте её в /etc/sysctl.d/99-kernel-hardening.conf:

iniКопировать
kernel.unprivileged_userns_clone=0

Примените без перезагрузки:

bashКопировать
sysctl --system

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

Во-первых, не ставьте неофициальные патчи из сторонних репозиториев. Во-вторых, мониторьте логи ядра и аномальные процессы. В-третьих, как только Canonical выпустит USN, обновляйтесь сразу — без откладывания на «потом». Предсказуемость инфраструктуры начинается с того, что вы знаете, что работает, а что нет, и не полагаетесь на авось.

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

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

Векторы атаки и условия эксплуатации

Уязвимость в ядре сама по себе не означает, что сервер будет взломан через пять минут. Для удалённого выполнения кода атакующий нуждается в начальной точке входа — обычно это локальный доступ к оболочке или возможность выполнить код от имени непривилегированного пользователя.

Уязвимость в ядре — как неисправный замок на входной двери в подъезд: сам по себе он не открывает двери в квартиры, но даёт злоумышленнику возможность попасть внутрь и действовать дальше.

С практической точки зрения вектор атаки на сервере выглядит так:

1. Атакующий получает выполнение кода в пользовательском пространстве — через уязвимое веб-приложение, скомпрометированный аккаунт по SSH или вредоносный контейнер.
2. Из пользовательского пространства он вызывает уязвимый системный вызов или взаимодействует с уязвимым драйвером ядра.
3. Если эксплуатация успешна, код выполняется с привилегиями ядра, и атакующий получает полный контроль над сервером.

Во-первых, не все ядра одинаково уязвимы. Многое зависит от версии, архитектуры и загруженных модулей. Например, на сервере с Ubuntu 22.04 LTS и ядром 5.15 набор уязвимых поверхностей отличается от ядра 6.8 на Ubuntu 24.04 LTS.

Во-вторых, важны условия эксплуатации. Некоторые уязвимости требуют, чтобы в системе был включён параметр kernel.unprivileged_userns_clone, другие — наличие конкретного устройства в /dev. Без этих условий эксплойт не сработает, даже если версия ядра совпадает.

Проверьте версию ядра на своих серверах:

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

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

bashКопировать
lsmod | grep -i <имя_модуля>

Если мы посмотрим на опыт прошлых лет, большинство инцидентов с ядром начинались не с удалённой атаки «извне», а с цепочки: веб-уязвимость → локальный доступ → эксплойт ядра. Предсказуемость здесь в том, что защита должна быть многослойной, а не полагаться на один патч.

Системный подход к безопасности описан в коллекции Навыки для настоящих инженеров: коллекция из .agents.

Какие системы находятся под угрозой

Под угрозой в первую очередь серверы на Ubuntu LTS, которые не получают обновления безопасности автоматически. Если unattended-upgrades отключён или настроен некорректно, патч не установится сам, и система останется уязвимой до ручного вмешательства.

Проверьте состояние автоматических обновлений:

bashКопировать
systemctl status unattended-upgrades

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

Веб-серверы тоже в зоне риска, даже если код выполняется от имени www-data. Локальная уязвимость ядра позволяет выйти за пределы учётной записи веб-сервера и получить root. То же самое касается узлов Proxmox и серверов с Docker: если контейнер имеет доступ к устройствам хоста или запущен с привилегиями, путь к ядру сокращается.

Системы без мониторинга и алертов на новые уязвимости находятся в самом сложном положении. Администратор может не узнать о проблеме, пока не произойдёт инцидент.

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

bashКопировать
ss -tulpn

Эта команда покажет, какие службы прослушивают сеть. Лишнее — отключить.

Что делать администратору до выхода патча

Что делать администратору до выхода патча

Временные меры снижения риска

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

Во-первых, ограничьте сетевой доступ к серверу. Если машина не должна быть доступна из интернета, закройте все порты, кроме необходимых. На Ubuntu проще всего использовать ufw:

bashКопировать
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

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

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

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

Если видите драйверы для оборудования, которого нет в стойке — например, беспроводных сетей или звука — выгрузите их и запретите автозагрузку через /etc/modprobe.d/:

bashКопировать
# /etc/modprobe.d/disable-unused.conf
install usb-storage /bin/true
install firewire-core /bin/true

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

bashКопировать
sudo update-initramfs -u

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

bashКопировать
# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AllowUsers admin

Перезапустите службу:

bashКопировать
sudo systemctl restart ssh

С точки зрения предсказуемости конфигурации, я всегда фиксируем такие изменения в Ansible или хотя бы в текстовом файле с комментариями. GUI для тех, кто не знает, где лежит конфиг — я правлю конфиги вручную. Если хотите подробнее про подход к инфраструктуре, читайте Навыки для настоящих инженеров: коллекция из .agents.

Мониторинг и обнаружение попыток эксплуатации

Патча нет, поэтому нужно понимать, когда кто-то пытается им воспользоваться. Я строю мониторинг на трёх уровнях: ядро, системные логи и сетевой трафик.

На уровне ядра полезно следить за аномалиями в dmesg и системном журнале. На Ubuntu по умолчанию используется journald, поэтому я смотрю сообщения ядра через:

bashКопировать
journalctl -k -b

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

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

bashКопировать
sudo apt install auditd
sudo auditctl -a exit,always -F arch=b64 -S execve -F uid=0 -k root_exec

Логи auditd пишутся в /var/log/audit/audit.log. Я подключаю их к Loki или к локальному файлу с ротацией, чтобы не потерять события после перезагрузки.

Сетевой мониторинг тоже важен. Если мы посмотрим на трафик, то увидим, что злоумышленник, скорее всего, будет отправлять нестандартные пакеты на открытые порты. Я использую Prometheus с node_exporter и Grafana для отслеживания всплесков входящего трафика, количества установленных соединений и количества отброшенных пакетов брандмауэром:

yamlКопировать
# Пример правила alerting в Prometheus
groups:
  - name: security
    rules:
      - alert: HighIncomingPackets
        expr: rate(node_network_receive_packets_total[5m]) > 10000
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Необычный входящий трафик на {{ $labels.instance }}"

Если видите резкий рост пакетов на порт, который должен быть закрыт, или нетипичные ответы от сервисов — проверяйте логи приложений и ядра.

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

bashКопировать
sudo apt install aide
sudo aideinit
sudo aide.wrapper --check

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

Альтернативы и долгосрочная защита

Альтернативы и долгосрочная защита

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

Переход на другие дистрибутивы или ядра

Первый вопрос, который задают коллеги: «А не переехать ли нам на Debian/RHEL/Arch?». Ответ зависит от того, сколько времени вы готовы потратить на миграцию и насколько критична простота поддержки.

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

• Debian stable — ядро обновляется реже, но патчи проходят тщательную проверку. Подходит, если стабильность важнее скорости.
• AlmaLinux / Rocky Linux — хорошая замена RHEL, если нужен долгосрочный цикл поддержки и коммерческий бэкап со стороны вендора.
• Arch Linux — ядро обновляется почти сразу после выхода апстрима, но rolling release требует больше внимания при обслуживании.
• Gentoo — можно наложить патч вручную ещё до сборки, но это для тех, кто готов тратить часы на компиляцию.

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

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

bashКопировать
uname -r
cat /etc/os-release

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

Сборка кастомного ядра с патчем

Если ждать патча из репозиториев Ubuntu нельзя, а переезжать на другой дистрибутив слишком дорого, остаётся собрать ядро самостоятельно. Это не сложнее, чем настроить сложный Nginx, но требует аккуратности.

Первое — установите инструменты для сборки:

bashКопировать
sudo apt update
sudo apt install build-essential libncurses-dev bison flex libssl-dev libelf-dev bc

Затем скачайте исходники ядра. Я предпочитаю брать их с официального сайта kernel.org, а не из сторонних репозиториев:

bashКопировать
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz
tar xvf linux-6.6.tar.xz
cd linux-6.6

Скопируйте конфигурацию текущего ядра, чтобы не гадать, какие модули нужны:

bashКопировать
cp /boot/config-$(uname -r) .config
make olddefconfig

Теперь наложите патч. Патч обычно приходит в виде unified diff, и накладывается командой patch:

bashКопировать
patch -p1 < /путь/к/безопасному/патчу.patch

Если патч не накладывается — проверьте версию ядра и контекст строк. Не пытайтесь править исходники вручную, если не уверены, что делаете.

Соберите ядро и модули:

bashКопировать
make -j$(nproc)
sudo make modules_install
sudo make install

После установки обновите конфигурацию загрузчика:

bashКопировать
sudo update-grub

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

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

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

Если вы не хотите собирать ядро вручную, но нужна защита прямо сейчас, посмотрите в сторону-патчинга (например, Canonical Livepatch или аналоги). Это позволяет наложить исправление без перезагрузки, но требует подписки и не всегда доступно для всех ядер.

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

Серверы должны работать предсказуемо. Любое изменение в ядре — это риск, который нужно документировать и мониторить.

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

Можно ли как-то снизить риск эксплуатации до выхода патча?

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

Что делать, если перезагрузка сервера невозможна в ближайшее время?

Оставьте сервер в текущем состоянии, но уже сейчас запланируйте окно для перезагрузки — патч не вступит в силу без неё. Пока ждёте подходящего момента, ужесточите правила межсетевого экрана и ограничьте доступ к серверу только доверенными IP. Как только появится возможность, установите обновление и перезагрузитесь.

Как проверить, уязвимо ли моё ядро?

Выполните uname -r и сравните версию со списком уязвимых сборок из статьи или из базы безопасности Ubuntu. Также полезно проверить установленные пакеты через apt list --installed | grep linux-image. Если версия совпадает с уязвимой, система требует обновления.

Стоит ли ставить ядро из бэкпортов или HWE вместо ожидания патча Ubuntu?

Переход на другое ядро без понимания причин задержки может привести к несовместимости модулей и драйверов, особенно на серверах с специфическим оборудованием. Лучше дождаться официального USN и обновиться через стандартные репозитории ubuntu-security. Эксперименты с ядром на продакшене снижают предсказуемость системы.

Поможет ли Ubuntu Pro получить патч быстрее?

Ubuntu Pro предоставляет расширенную поддержку безопасности, но патч для 0day всё равно проходит внутреннюю проверку Canonical перед выпуском. Наличие подписки не гарантирует мгновенного фикса, хотя может ускорить доставку обновления после его релиза. Если у вас уже есть Pro, включайте -proposed или -updates только после подтверждения стабильности пакета.