SlowMist попередження: Linux критична вразливість для підвищення привілеїв, негайно вимкніть три модулі для екстреного пом’якшення

Головний офіцер з інформаційної безпеки Slow Mist 23pds повідомив 8 травня про те, що в Linux-системах є критична вразливість підвищення привілеїв під назвою Dirty Frag. Повні деталі та код для використання вже оприлюднено: будь-який локальний користувач із низькими правами може без жодних спеціальних умов системи напряму отримати root-адміністраторські права на ураженій системі. Невідкладні заходи з пом’якшення ризиків — вимкнути модулі esp4, esp6 і rxrpc.

Чому Dirty Frag настільки небезпечний: логічна вразливість, дуже висока ймовірність успіху, без патча

Dirty Frag належить до визначальних логічних уразливостей, а не до нестабільних атак, що залежать від умов змагання (race conditions). Це робить її надзвичайно високоефективною та сталою у відтворенні. Атакувальнику достатньо виконати невелику програму, щоб одразу отримати root-доступ цільової системи; увесь процес не спричиняє падіння ядра й практично не піддається виявленню типовими засобами моніторингу.

Вразливість 30 квітня безпекові дослідники передали команді розробників ядра Linux, але до завершення робіт із виправлення «незалежна третя сторона» завчасно розкрила детальну інформацію та код використання, через що безпекову заборону довелося скасувати. У безпековій спільноті загалом вважають, що це означає: зловмисні актори, ймовірно, вже активно експлуатують цю вразливість.

З технічної точки зору Dirty Frag і механізм вразливості Copy Fail, який наразі спричиняє широкі проблеми у сфері Linux-серверів, є подібними: обидві реалізують атаку шляхом вбудовування дескриптора опису сторінкового кешу в операцію без копіювання (zero-copy). Базова вразливість «xfrm-ESP Page-Cache Write» була внесена комітом ядра cac2661c53f3 від 2017 року. Оскільки в Ubuntu AppArmor виправив цю проблему, PoC підв’язує другу вразливість «RxRPC Page-Cache Write» (коміт 2dc334f1a63a), щоб гарантувати, що атака в Ubuntu також працюватиме.

Масштаб ураження: перелік основних Linux-дистрибутивів, які вже підтверджені

Підтверджені уражені Linux-дистрибутиви (частково):

· Ubuntu 24 і Ubuntu 26 (включно з AppArmor, через обхід другою вразливістю)

· Arch Linux (також підтверджено, з оновленими версіями)

· RHEL (Red Hat Enterprise Linux)

· OpenSUSE

· CentOS Stream

· Fedora

· AlmaLinux

· CachyOS (підтверджено тригер на ядрі версії 7.0.3-1-cachyos)

· WSL2 (Windows Subsystem for Linux) також підтверджено як уражений

Невідкладні заходи з пом’якшення ризиків: конкретні команди для вимкнення трьох модулів

До виходу офіційних патчів найефективніший спосіб пом’якшення — вимкнути модулі esp4, esp6 і rxrpc. Ці три модулі пов’язані з мережевою функціональністю IPSec; якщо сервер сам по собі не є IPSec-клієнтом або сервером, то після вимкнення це майже не вплине на звичайну роботу.

Щоб вимкнути модулі, виконайте такі команди: sh -c “printf ‘install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n’ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true”

Після завершення запустіть детальний моніторинг безпекових повідомлень для кожного Linux-дистрибутива та одразу після офіційного виходу патчів розгорніть системні оновлення.

Поширені запитання

Чи є на сьогодні офіційний патч для вразливості Dirty Frag?

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

Чи вплине вимкнення модулів esp4, esp6 і rxrpc на нормальну роботу сервера?

Ці три модулі переважно пов’язані з IPSec-протоколами. Якщо сервер сам по собі не є IPSec-клієнтом або сервером (тобто використовується для шифрованого зв’язку на мережевому рівні), то вимкнення практично не вплине на типові сценарії на кшталт вебсервісів, баз даних, шифрувальних вузлів тощо. Наразі це найбезпечніший і найменш інвазивний невідкладний спосіб пом’якшення ризиків.

Чому цього разу вразливість оприлюднили без патча?

У галузі прийнята практика «відповідального розкриття» — коли безпекові дослідники передають вразливість виробнику, зазвичай вони чекають завершення патча, перш ніж публікувати деталі. Цю вразливість подали 30 квітня, але «незалежна третя сторона» завчасно розкрила детальну інформацію, зламавши заборону. Безпекові дослідники припускають, що зловмисні атакувальники могли вже активно експлуатувати цю вразливість, і саме це стало причиною остаточного скасування заборони.