Компания OpenAI 4 ноября 2026 года опубликовала отчёт о масштабном исследовании уязвимостей ядра Linux (A thousand fewer paths to root). Агент на ещё не вышедшей модели сам выбирал код для анализа, сканировал его, воспроизводил находки в изолированных средах, проверял возможность эксплуатации и создавал патчи. Итог — 1724 воспроизведённых уязвимости, из которых 948 относятся к классу LPE — повышение прав локального процесса до root. Напрямую переносить это число на конкретный VPS нельзя: исследование проводилось на master-версии ядра и не доказывает уязвимость каждого дистрибутива и каждой конфигурации. Но сама технология поиска принципиально меняет масштаб проблемы.
Данные проверены 5 ноября 2026 года.
Ключевые термины и масштаб
| Обозначение | Определение |
|---|---|
| 1724 | Все воспроизведённые уязвимости ядра — класс LPE здесь лишь подмножество. |
| 1169 | Число рабочих LPE-эксплойтов до разбора вариантов — один дефект может дать несколько эксплойтов. |
| 948 | Уникальные LPE, определённые по различным патчам. |
Пайплайн исследования официально состоит из пяти этапов: обнаружение (выбор целей и анализ кода), динамическая валидация, проверка эксплуатируемости, генерация патчей и человеческое ревью. Анализ охватывал master-версию ядра на середину октября 2026 года: приоритизированную проверку около 7% кода (5034 цели, порядка 2,8 млн строк), а не полный аудит. Защиты вроде SMEP, SMAP, KASLR и HARDENED_USERCOPY в тестовых виртуальных машинах были включены, но это не гарантирует одинаковую уязвимость всех дистрибутивов. Важно и разграничение чисел: 1169 — эксплойты, 948 — дефекты, требующие отдельных кандидатных исправлений; это не принятые upstream-патчи и не присвоенные CVE. Человеческая проверка и согласование с мейнтейнерами остаются обязательными этапами.
Что такое LPE на примере взломанного веб-сервиса
LPE — повышение прав уже исполняемого на хосте локального процесса. Иллюстративный сценарий: в веб-приложении находят удалённое исполнение кода, и атакующий получает процесс от имени непривилегированного пользователя — например, www-data. Дальше решает локальная эскалация: если ядро уязвимо и найденный дефект позволяет, процесс через ошибку в системном вызове, гонке или обращении к памяти получает права root.
Экономика: сколько стоит путь от ошибки до патча
По опубликованным OpenAI данным, агент потратил 1 213 430 долларов API-кредитов на 948 уникальных LPE — порядка 1280 долларов за находку. Для сравнения возьмём исторические премии конкурсов: около 20 000 долларов на Pwn2Own и до 70 000 на TyphoonPWN. Гипотетическое умножение таких ставок на 948 даёт диапазон 18,96–66,36 млн долларов. Это не реальные выплаты и не выручка: критерии конкурсов отличаются, премии платятся за избранные эксплойты, а API-расходы не покрывают обучение модели, труд людей и внедрение.
Почему uname -r недостаточно
Первая привычка, от которой стоит отказаться, — судить о защищённости ядра по его версии. Строка вида 4.18.0-xxx или 5.15.0-xxx означает базовый upstream-релиз, к которому дистрибутив применяет собственные наборы исправлений. Red Hat и производные дистрибутивы переносят security fixes из новых upstream-версий обратно в старые поддерживаемые пакеты, поэтому «старое» по номеру ядро может быть полностью пропатчено, а «новое» — требовать отдельной проверки по свежему advisory (Red Hat: принципы бэкпортирования). Сравнение только номера ядра из uname -r со списком CVE малоинформативно: без указания vendor-релиза пакета и конкретного advisory оно не отвечает на вопрос, какие исправления внутри. Единственный корректный способ — сопоставлять пакетную версию и сборку ядра с номером конкретного vendor advisory вашего дистрибутива.
Второй момент — uname -r показывает, какое ядро исполняется прямо сейчас, а пакетный менеджер — какое установлено. После обновления без перезагрузки эти значения расходятся: если livepatch не применяется, система продолжает работать на прежнем коде в памяти, даже если на диске лежит исправленный. Любая проверка «а пропатчен ли я» обязана сравнивать оба значения.
Что делать владельцу VPS: порядок действий
Сначала три команды, которые ничего не меняют в системе и дают базовую картину:
cat /etc/os-release
uname -r
uname -mПервая показывает дистрибутив и его версию — то есть чей advisory читать; дату окончания поддержки дистрибутива и конкретного релиза проверяют отдельно по данным вендора. Вторая — версию запущенного ядра, с которым система работает в данный момент. Третья — архитектуру процессора, без которой нельзя подобрать правильный пакет ядра (x86_64 и aarch64 имеют разные сборки и, иногда, разные сроки поддержки).
- Проверьте статус поддержки ОС. Если дистрибутив вышел из сопровождения, обновления ядра просто не будут выходить — никакая гигиена это не компенсирует. Это основание для планирования миграции.
- Найдите официальный vendor advisory. Для вашего дистрибутива ищите не новости и не блоги, а исходный advisory (RHSA, DSA, USN и т.п.) с указанием исправленных версий пакетов. Сторонние пересказы регулярно ошибаются в номерах.
- Сопоставьте advisory с вашим пакетом. Сравните версию установленного пакета ядра с указанной в advisory — через штатный пакетный менеджер (rpm -q, dpkg -s или эквивалент), а не через uname -r, по причинам из предыдущего раздела.
- Проверьте возможность отката и доступ к консоли. Перед перезагрузкой убедитесь, что у вас есть VNC-консоль или её аналог в панели провайдера и вы понимаете, как загрузиться с предыдущим ядром из загрузчика. Если доступа к консоли нет, согласуйте это с поддержкой заранее — повреждённый bootloader без консоли чинить будет нечем.
- Сделайте резервную копию. Полный снимок диска; если он невозможен — как минимум /etc, /boot, список пакетов, данные приложения и согласованный по состоянию бэкап базы данных, с проверенным восстановлением. Обновление ядра — операция с классическим риском «сервер не поднялся после reboot», и бэкап здесь дешевле любых рассуждений.
- Обновите ядро штатным пакетным менеджером дистрибутива в согласованное окно обслуживания. Не собирайте ядро из исходников и не ставьте пакеты из сторонних репозиториев на production: вы теряете связь с vendor advisory и гарантии совместимости. Не скачивайте «патчи» по ссылкам из мессенджеров и соцсетей — это стандартный канал доставки вредоноса.
- Перезагрузитесь и проверьте результат. После reboot убедитесь, что uname -r соответствует установленному пакету, сервисы поднялись (sshd, веб-сервер, базы данных, мониторинг), а старое ядро осталось в меню загрузчика как запасной вариант.
Livepatch: что он даёт и чего не обещает
Canonical Livepatch применяет отдельные исправления к запущенному ядру без перезагрузки. Механизм покрывает high и critical CVE, когда для дефекта технически возможен livepatch; если он невозможен, клиент сообщит, что требуется обычное обновление пакета и reboot (документация Livepatch: типы обновлений). Проверить состояние можно командой canonical-livepatch status, если она уже установлена: вывод показывает kernel state и patch state. «Все применимые livepatch загружены» означает, что загружено всё, что Canonical выпустила для вашего ядра, — и не более того. Поэтому livepatch — способ сократить окна до перезагрузки, а не альтернатива регулярному обновлению ядра.
Контейнеры и shared-хостинг
Частая ошибка: обновить образ контейнера и считать задачу закрытой. Обычный Linux-контейнер Docker не имеет собственного ядра — он исполняется на ядре хоста, однако доступность конкретной LPE определяется дефектом и конфигурацией контейнера. Обновление приложения внутри образа, смена base image, даже пересборка всего стека не трогают уязвимый код в памяти хоста. Патчить нужно именно ядро машины, на которой работает Docker.
Дополнительно стоит ограничить последствия: выдавать контейнерам минимальные capabilities, не запускать с привилегированными флагами без необходимости, подключать AppArmor или SELinux. Отдельно — не раздавать docker.sock сервисам, которым он не нужен: доступ к Docker daemon в стандартном rootful-режиме эквивалентен root на хосте; rootless-режим запускается в другом контексте прав. Namespaces и capabilities снижают поверхность атаки, а cgroups ограничивают потребление ресурсов; это не даёт абсолютной гарантии — сочетание kernel bug с неудачной конфигурацией может нарушать изоляцию (Docker Docs: Engine security). Реализуемость конкретной эскалации за пределы контейнера зависит от самого дефекта и настроек окружения.
На managed-хостинге и в облаке, где ядро не ваше, распределение ответственности за обновление зависит от типа услуги (VM, контейнер, managed-сервис) и договора с провайдером. Запросите у него: применяется ли к ядру политика своевременных security updates, уведомляет ли он о planned reboot и предоставляет ли live-миграцию или livepatch. Ответы на эти вопросы стоит закладывать в выбор провайдера заранее, а не после инцидента.
Замечание для security-команд
При разборе находок полезен минимальный воспроизводимый сценарий: короткий reproducer, конфигурация ядра и окружения, где он срабатывает. Сначала формулируется гипотеза о корне причины — какой именно дефект в коде делает возможной эскалацию, — затем проверяется реальный путь эксплуатации в вашей конфигурации, а не теоретическая возможность. Отдельно фиксируются варианты исправления и связанные с ними риски регрессий. Куда и как сообщать о проблемах ядра, описано в официальной документации (Kernel.org: reporting issues); для vendor-ядра предпочтителен канал самого дистрибутива.
Частые вопросы
Можно ли эксплуатировать эти LPE через интернет, без доступа к серверу?
Сама по себе LPE требует локального исполнения кода на машине. Возможный сценарий — цепочка: сначала удалённое исполнение кода в уязвимом веб-приложении, затем эскалация через ядро. Наличие большого числа путей к root повышает ценность каждой исходной точки входа. Фаервол, ограничивающий HTTP-доступ, полезен, но не заменяет патченное ядро.
Существует ли один универсальный патч для всего?
Нет. Единого универсального патча для всех 948 LPE не существует: для каждой уязвимости подготовлено отдельное кандидатное исправление, и не все они приняты upstream. Для своей системы отслеживайте выпущенные vendor advisory и исправленные версии пакетов, устанавливайте обновления и проверяйте, что работает обновлённое ядро.
Обновление ядра очищает уже скомпрометированный сервер?
Нет. Патч закрывает конкретный путь эскалации, но не трогает ни следы, ни закрепление атакующего, ни украденные ключи. При признаках компрометации порядок иной: изолировать систему, сохранить журналы, восстановить сервис на чистой системе и заменить все секреты, а не латать ядро на заражённом хосте.
