Chief Information Security Officer Mist Wu mengungkapkan pada 8 Mei bahwa sistem operasi Linux memiliki kerentanan serius peningkatan hak istimewa bernama Dirty Frag; detail lengkap dan kode eksploitnya telah dipublikasikan. Setiap pengguna lokal dengan hak rendah dapat langsung memperoleh hak akses administrator root pada sistem yang terdampak tanpa perlu kondisi sistem tertentu. Tindakan mitigasi darurat adalah menonaktifkan tiga modul: esp4, esp6, dan rxrpc.
Mengapa Dirty Frag begitu berbahaya: celah logika, tingkat keberhasilan tinggi, tanpa patch
Dirty Frag termasuk dalam kerentanan logika yang deterministik, bukan serangan yang tidak stabil akibat kondisi perlombaan, sehingga tingkat keberhasilannya sangat tinggi dan dapat direproduksi secara konsisten. Penyerang hanya perlu menjalankan program kecil untuk segera mendapatkan hak root pada sistem target; proses ini tidak menyebabkan inti (kernel) mengalami crash, sehingga sangat sulit terdeteksi oleh pemantauan standar.
Kerentanan ini diajukan pada 30 April oleh peneliti keamanan kepada tim inti Linux, tetapi sebelum pekerjaan penambalan selesai, “pihak ketiga yang tidak terkait” lebih dulu membocorkan detail informasi dan kode eksploit, sehingga larangan keamanan terpaksa dicabut. Komunitas keamanan secara luas menganggap ini berarti penyerang berbahaya mungkin sudah memanfaatkan celah tersebut secara aktif.
Dari prinsip teknis, Dirty Frag mirip dengan mekanisme celah Copy Fail yang saat ini menyebabkan kerusakan luas di ranah server Linux: keduanya melakukan serangan dengan menyisipkan deskriptor cache halaman ke dalam operasi zero-copy. Celah akar “xfrm-ESP Page-Cache Write” diperkenalkan oleh commit inti tahun 2017 cac2661c53f3; karena perbaikan AppArmor Ubuntu menutup celah ini, PoC mengaitkan celah kedua “RxRPC Page-Cache Write” (commit 2dc334f1a63a) untuk memastikan serangan tetap efektif pada sistem Ubuntu.
Ruang lingkup terdampak: daftar distribusi Linux arus utama yang telah dikonfirmasi
Distribusi Linux yang telah dikonfirmasi terdampak (sebagian):
· Ubuntu 24 dan Ubuntu 26 (termasuk AppArmor, melalui bypass celah kedua)
· Arch Linux (versi yang telah diperbarui juga dikonfirmasi terdampak)
· RHEL (Red Hat Enterprise Linux)
· OpenSUSE
· CentOS Stream
· Fedora
· AlmaLinux
· CachyOS (versi inti 7.0.3-1-cachyos telah dikonfirmasi memicu)
· WSL2 (Windows Subsystem for Linux) juga dikonfirmasi terdampak
Tindakan mitigasi darurat: perintah spesifik untuk menonaktifkan tiga modul
Sebelum rilis patch resmi, metode mitigasi paling efektif adalah menonaktifkan tiga modul esp4, esp6, dan rxrpc. Ketiga modul ini terkait dengan fitur jaringan IPSec; kecuali server itu sendiri merupakan klien atau server IPSec, maka setelah dinonaktifkan hampir tidak memengaruhi aktivitas bisnis normal.
Jalankan perintah berikut untuk menyelesaikan penonaktifan modul: 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"
Setelah selesai, harap pantau dengan saksama pengumuman keamanan dari masing-masing distribusi Linux, lalu segera terapkan pembaruan sistem setelah patch resmi dirilis.
Pertanyaan Umum
Apakah patch resmi untuk kerentanan Dirty Frag sudah tersedia saat ini?
Hingga saat ini, pihak resmi belum merilis patch apa pun, dan belum terlihat adanya commit perbaikan pada inti lini utama Linux. Ini terjadi karena larangan keamanan rusak lebih dulu sebelum pekerjaan patch selesai, sehingga detail kerentanan terekspos saat proses perbaikan belum tuntas. Administrator sistem harus memantau dengan saksama pengumuman keamanan distribusi Linux, lalu segera menerapkan setelah patch dirilis.
Apakah menonaktifkan modul esp4, esp6, dan rxrpc akan memengaruhi operasi normal server?
Ketiga modul ini terutama terkait dengan protokol IPSec. Kecuali jika server itu sendiri adalah klien atau server IPSec (yakni untuk komunikasi enkripsi lapisan jaringan), maka menonaktifkan modul-modul tersebut hampir tidak akan memengaruhi layanan Web, basis data, node enkripsi, dan aktivitas umum lain. Ini adalah solusi mitigasi darurat paling aman dengan dampak paling minimal saat ini.
Mengapa kerentanan ini dipublikasikan tanpa adanya patch lebih dulu?
Kebiasaan di industri adalah “respons tanggung jawab”—setelah peneliti keamanan mengajukan laporan kerentanan ke vendor, biasanya mereka menunggu hingga patch selesai sebelum detail dipublikasikan. Kerentanan ini diajukan pada 30 April, tetapi “pihak ketiga yang tidak terkait” membocorkan detail informasi lebih dulu, sehingga larangan terlepas. Peneliti keamanan menduga pelaku serangan berbahaya mungkin sudah memanfaatkan celah ini secara aktif; inilah pemicu utama dicabutnya larangan tersebut.
