Новий Linux-вашій загрозі: Dirty Frag — підвищення привілеїв

З’явилася нова проблема підвищення привілеїв у Linux, відома як Dirty Frag. Ця загроза виникла всього через кілька днів після оголошення про Copy Fail, додаючи ще одну термінову проблему безпеки для екосистеми Linux. Це особливо стосується адміністраторів, які управляють серверами, контейнерами, CI-інстальованими системами та загальними платформами.

Чому Dirty Frag є небезпечним?

Dirty Frag є вразливістю підвищення привілеїв, яка не дозволяє віддалене виконання коду. Вона дозволяє некваліфікованим локальним користувачам, скомпрометованим контейнерам, завданням CI або іншим процесам отримати привілеї root на уражених системах.

Дослідник безпеки Hyunwoo Kim опублікував деталі про Dirty Frag. Він описав цю вразливість як такий клас вразливостей, який об’єднує дві проблеми запису кешу сторінок у ядрі Linux. Перша проблема стосується шляху IPsec ESP/XFRM (CVE-2026-43284), а друга — RxRPC (CVE-2026-43500).

Відмінності Dirty Frag від Copy Fail

Dirty Frag є подібною до Copy Fail за наслідками, але представляє собою окрему вразливість. Якщо Copy Fail вплинула на криптосистему ядра Linux через algif_aead, то Dirty Frag пов’язана з мережевими шляхами, що стосуються IPsec ESP/XFRM та RxRPC.

Ця вразливість є частиною ширшої категорії проблем корупції кешу сторінок, наприклад, таких як Dirty Pipe і Copy Fail. Атака експлуатує шляхи ядра, які обробляють буфери з підібраними даними, відкриваючи записні примітиви в кеші сторінок. Публічний код доказів концепції доступний, що підвищує терміновість дій з боку дистрибутивів та адміністраторів.

Системи з найвищим ризиком

Найбільш ризикованими оточеннями є багатокористувацькі сервери, системи спільного хостингу, CI/CD-інсталятори, хости контейнерів, вузли Kubernetes та будь-яка система, де ненадійні користувачі або навантаження можуть виконувати код.

Крім того, Canonical повідомляє, що вразливість також важлива для контейнерних розгортань із сторонніми навантаженнями. Це може дозволити перенести контейнер, крім локального підвищення привілеїв. Наразі не опубліковано доказу концепції для втечі з контейнера.

Доступність патчів для Dirty Frag

Доступність патчів залежить від дистрибутива. AlmaLinux випустив патчі для версій 8, 9 та 10 у своєму тестовому репозиторії, а просування до продуктивних версій ще в процесі. Трекер Debian вказує, що CVE-2026-43284 було виправлено лише в Debian sid із версією ядра Linux 7.0.4-1. На даний момент версії Bullseye, Bookworm, Trixie і Forky залишаються вразливими.

Ubuntu надала рекомендації щодо пом’якшення ситуації і вказує, що на вразливість впливають версії Ubuntu 14.04 LTS, 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, 24.04 LTS, 25.10 та 26.04 LTS. Трекер CVE Canonical вказує, що кілька пакетів ядра Ubuntu все ще потребують оцінки. Виправлення буде розподілено через пакети зображень ядра Linux, коли вони стануть доступними.

Red Hat підтверджує, що Red Hat Enterprise Linux 8, 9 та 10, а також OpenShift 4 підлягають вразливості. Компанія прискорює виправлення і надасть специфічні рекомендації для продукту. Проблема залишається у стадії розгляду в її консультаціях. openSUSE та SUSE також відслідковують Dirty Frag, засвідчуючи, що вплинули поточні ядра Leap 16.0 та Tumbleweed.

Рекомендації щодо виправлення Dirty Frag

Рекомендується застосувати патч для ядра і перезавантажити систему. Тимчасове пом’якшення ситуації від продавців полягає в вимкненні вразливих модулів, які не є необхідними, включаючи blacklist для esp4, esp6 та rxrpc. Деякі рекомендації також включають blacklist для модулів стиснення IPsec, таких як ipcomp4 та ipcomp6.

Однак цей обхідний шлях не підходить для всіх систем. Вимкнення цих модулів може порушити функціонування машин, які використовують IPsec VPN, strongSwan, Libreswan, AFS, RxRPC або пов’язані мережеві фічі. Canonical застерігає, що пом’якшення вплине на функціональність IPsec ESP та RxRPC, і що вимкнення лише одного компонента залишає інший вразливим.

Адміністратори повинні оновити ядро як тільки стануть доступними патчі. Після цього необхідно перезавантажити систему у виправлене ядро, а застосовувати тимчасове чорний список модулів лише якщо вразлива функціональність не є необхідною. У середовищах з великим використанням контейнерів та багатокористувацькими системами, слід розглядати Dirty Frag як проблему безпеки ядра Linux високого пріоритету.