Нова вразливість локального підвищення привілеїв у ядрі Linux, розкрита Theori/Xint, дає змогу будь-якому непривілейованому локальному користувачу отримати права root за допомогою скрипта Python розміром 732 байти. Спрацьовує з першої спроби, без race condition і без адаптації під конкретну версію ядра. Оцінка CVSS – 7.8, але для середовищ зі спільним ядром і мультитенантних середовищ фактична критичність може бути вищою.
Вразливість
Логічна помилка в algif_aead ядра, додана у версії 4.14 у липні 2017 року, експлуатується через AF_ALG і splice(). Вона забезпечує детермінований 4-байтовий запис у page cache будь-якого доступного для читання файлу, зокрема setuid-бінарних файлів.
- Без race condition, без адаптації під конкретну версію ядра, спрацьовує з першої спроби.
- Файл на диску не змінюється, тому засоби контролю цілісності файлів цього не виявлять.
- Page cache є спільним у межах хоста, що робить цю вразливість основою для потенційного виходу за межі контейнера на вузлах Kubernetes із будь-якого pod, який може створювати сокети AF_ALG.
Кого це стосується
Усіх версій ядра від 4.14 до виправлення. Theori підтвердила отримання root-прав на Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 і SUSE 16. Той самий експлойт без змін працює на Debian, Fedora, Rocky, Alma, Oracle та Arch. Виправлення доступне у версіях 6.18.22, 6.19.12 і 7.0.
Що робити
На момент розкриття більшість дистрибутивів ще не постачали виправлені ядра. Спочатку слід застосувати пом’якшувальні заходи, а після появи виправлення – встановити оновлення.
1. Вимкнути algif_aead на кожному хості:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || trueБезпечно для застосування: це не впливає на dm-crypt, kTLS, IPsec, OpenSSL, SSH або криптографію kernel keyring. Вплив є лише на застосунки, які явно використовують OpenSSL afalg engine.
2. Заблокувати AF_ALG через seccomp для ненадійних робочих навантажень, таких як Kubernetes, середовища виконання CI та пісочниці для агентів.
3. Встановити оновлення ядра одразу після того, як дистрибутив постачатиме виправлення, а потім перезавантажити систему.
4. Пріоритетність: мультитенантні вузли Kubernetes, потім середовища виконання CI, потім продакшн-сервери, потім робочі станції.
Для команд, що працюють із хмарною інфраструктурою
CVE ядра не відображаються в SBOM образів, тому виявлення має виконуватися на рівні вузла. Робочі навантаження, що запускаються під апаратною віртуалізацією (наприклад Firecracker для Lambda або Fargate), чи в середовищах із повторною реалізацією ядра (таких як gVisor або V8 isolates), не мають доступу до механізму AF_ALG у ядрі хоста, тому ця вразливість на них не поширюється.
