КИБЕРБЕЗОПАСНОСТЬ

DirtyClone в Linux дает root без следов на диске

CVE-2026-43503 с оценкой 8,8 по CVSS позволяет локальному пользователю получить root в Linux через cloned packets и обходить file-integrity checks.

✍️ Редакция iTech News | 27.06.2026 | ⏱ 4 мин | Источник: The Hacker News
🔐

В Linux нашли уязвимость DirtyClone — локальную привилегированную эскалацию CVE-2026-43503 с оценкой 8,8 по CVSS, которая позволяет обычному пользователю получить root, не меняя файл на диске. Для команд, которые держат multi-tenant серверы, CI runners, контейнерные хосты и Kubernetes-кластеры, история неприятная: атака живет в page cache, почти не оставляет следов и легко проходит мимо систем контроля целостности.

О новой дыре DirtyClone сообщает The Hacker News со ссылкой на JFrog Security Research, опубликовавшую 25 июня рабочий разбор эксплуатации. Суть бага довольно злая и при этом типично "линуксовая": при внутреннем клонировании сетевого пакета ядро в некоторых путях теряет защитный флаг, который помечает память как разделяемую с файлом на диске. Дальше локальный атакующий подгружает, например, /usr/bin/su в память, привязывает соответствующие страницы к сетевому пакету и заставляет ядро клонировать этот пакет. После прохождения через подконтрольный IPsec-туннель стадия расшифровки перезаписывает байты в памяти, в том числе проверку логина в su. Следующий запуск бинарника отдает root.

Самая неприятная деталь: файл на диске при этом не меняется. Меняется только его копия в памяти ядра, то есть page cache. Для защитных средств это почти издевательство: file-integrity monitoring смотрит на файл и видит, что он чистый; аудиторский след минимален; после перезагрузки все возвращается к исходному состоянию. Но к этому моменту атакующий уже получил root и, скорее всего, успел закрепиться. Для инфраструктурных команд это означает простую вещь: проверка хеша бинарника после инцидента может не показать вообще ничего.

Есть и важная оговорка. Эксплуатация требует CAP_NET_ADMIN, потому что злоумышленнику нужен loopback IPsec-туннель. На бумаге это выглядит как ограничение, на практике — не всегда. На Debian и Fedora непривилегированные user namespaces включены по умолчанию, поэтому локальный пользователь может получить нужную capability внутри нового namespace. Ubuntu 24.04 и новее режет этот путь через AppArmor и тем самым ломает стандартную цепочку эксплуатации. Проблема в том, что page cache общий на уровне хоста, так что изменения, сделанные внутри namespace, влияют на все процессы на машине. Именно поэтому под ударом оказываются не столько ноутбуки разработчиков, сколько shared-серверы, раннеры CI, хосты с контейнерами и кластеры, где недоверенные пользователи могут создавать namespaces.

DirtyClone — уже не отдельная неприятность, а четвертый эпизод в серии. В конце апреля всплыл Copy Fail с CVE-2026-31431, где модуль algif_aead позволял четырехбайтовую запись в page cache. 7 мая появился DirtyFrag с CVE-2026-43284 и CVE-2026-43500, который уже давал полноценную запись через цепочку IPsec ESP и RxRPC. 13 мая исследователи показали Fragnesia, CVE-2026-46300: она обходила прошлый патч из-за потери того же флага в skb_try_coalesce(). Теперь DirtyClone показал еще один путь — через __pskb_copy_fclone(); по данным статьи, затронут и skb_shift(). Вывод для разработчиков ядра неприятный, но полезный: это не баг одной функции, а поломанный контракт на уровне всей подсистемы. Если любой код, который переносит skb-фрагменты, забывает протащить флаг shared-frag, оптимизация zero-copy внезапно превращается в write primitive.

Патч, закрывающий CVE-2026-43503, попал в mainline 21 мая, CVE присвоили 23 мая, а 24 мая исправление вошло в Linux v7.1-rc5. The Hacker News пишет, что более широкий патч на несколько уязвимых путей еще 16 мая предложил исследователь DirtyFrag Хёнву Ким, а итоговый коммит с объединенным исправлением получил идентификатор 48f6a5356a33. Для бизнеса здесь важен не академический интерес к внутренностям сетевого стека, а скорость обновления дистрибутивных ядер: если ваш kernel не содержит этот набор фиксов, у вас есть локальная дорожка до root, которая особенно неприятна в средах с несколькими арендаторами и автоматизированным пайплайном сборки.

Практические меры довольно скучные, а значит, рабочие. Первая и нормальная — ставить обновление ядра: upstream-фикс уже ушел в stable и LTS-ветки, а Ubuntu, Debian и SUSE выпустили advisories; у Red Hat есть Bugzilla-трекинг. Временные костыли тоже есть, но они именно временные. Можно ограничить непривилегированные user namespaces, например через kernel.unprivileged_userns_clone=0 на Debian и Ubuntu. Можно заблокировать модули esp4, esp6 и rxrpc, но тогда ломаются IPsec и AFS, и этот вариант помогает только если нужные функции собраны как модули, а не вшиты в ядро. Для SRE и платформенных команд это еще один аргумент не раздавать namespace-возможности там, где без них можно обойтись.

Главный вопрос теперь не в том, закрыт ли именно DirtyClone, а в том, сколько еще похожих путей живет в сетевом стеке Linux. Семейство DirtyFrag уже несколько раз показало одну и ту же картину: фикс закрывает конкретную тропинку, а следующий вариант находит соседнюю. Для экосистемы Linux это плохая новость ровно в той мере, в какой zero-copy и сложные цепочки обработки пакетов стали нормой. Чем агрессивнее ядро экономит копирования, тем дороже обходится один потерянный бит в метаданных. Подробнее о разборе эксплуатации — в материале The Hacker News.

Поделиться: Telegram X LinkedIn