Dirty Frag: Kerentanan LPE Linux universal (eskalasi hak istimewa lokal)

 (openwall.com)
2 poin oleh GN⁺ 2 jam lalu | 2 komentar | Bagikan ke WhatsApp
  • Dirty Frag adalah kerentanan eskalasi hak istimewa lokal universal yang memungkinkan perolehan hak root di berbagai distribusi Linux utama, dan karena jadwal responsible disclosure serta embargo telah rusak, belum ada patch maupun CVE
  • Sebagai perluasan dari kelas bug seperti Dirty Pipe dan Copy Fail, karena ini adalah bug logika deterministik, race condition tidak diperlukan dan tingkat keberhasilannya sangat tinggi
  • Masa berlaku efektif kerentanan ini sekitar 9 tahun, dan telah diuji pada distribusi utama seperti Ubuntu, RHEL, Fedora, dan openSUSE
  • Bahkan pada sistem yang telah menerapkan mitigasi Copy Fail yang ada (blacklist algif_aead), sistem tersebut tetap rentan terhadap Dirty Frag
  • Sebagai mitigasi sementara hingga patch distribusi tersedia, disarankan untuk menghapus modul esp4, esp6, dan rxrpc yang memicu kerentanan

Ringkasan

  • Kelas bug yang mengotori anggota frag dari struktur sk_buff, merupakan perluasan dari kelas bug yang sama dengan Dirty Pipe dan Copy Fail
  • Dengan merangkai kerentanan xfrm-ESP Page-Cache Write dan RxRPC Page-Cache Write, dimungkinkan memperoleh hak root pada distribusi Linux utama
  • Karena merupakan bug logika deterministik, tidak bergantung pada timing window, sehingga race condition tidak diperlukan
  • Bahkan saat eksploit gagal, kernel panic tidak terjadi, dan tingkat keberhasilannya sangat tinggi

Alasan merangkai dua kerentanan

  • xfrm-ESP Page-Cache Write menyediakan primitif STORE 4-byte arbitrer yang kuat mirip dengan Copy Fail dan disertakan di sebagian besar distribusi, tetapi memerlukan izin pembuatan namespace
  • Pada Ubuntu, dalam beberapa kasus kebijakan AppArmor memblokir pembuatan user namespace tanpa hak istimewa, sehingga dalam lingkungan ini xfrm-ESP Page-Cache Write tidak dapat dipicu
  • RxRPC Page-Cache Write tidak memerlukan izin pembuatan namespace, tetapi modul rxrpc.ko sendiri tidak disertakan di sebagian besar distribusi
    • Namun, pada Ubuntu modul rxrpc.ko dimuat secara default
  • Dengan merangkai kedua kerentanan tersebut, kelemahan masing-masing saling melengkapi, sehingga perolehan hak root dimungkinkan di semua distribusi utama

Hubungan dengan Copy Fail

  • Copy Fail adalah motivasi yang memulai riset ini
  • xfrm-ESP Page-Cache Write berbagi sink yang sama dengan Copy Fail, tetapi dapat dipicu terlepas dari ketersediaan modul algif_aead
  • Bahkan pada sistem yang telah menerapkan mitigasi Copy Fail yang dipublikasikan (blacklist algif_aead), sistem tetap rentan terhadap Dirty Frag

Cakupan dampak

  • xfrm-ESP Page-Cache Write: dari commit cac2661c53f3 (2017-01-17) hingga upstream
  • RxRPC Page-Cache Write: dari commit 2dc334f1a63a (2023-06) hingga upstream
  • Masa berlaku efektif kerentanan sekitar 9 tahun
  • Versi distribusi yang telah diuji:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

Mitigasi

  • Karena jadwal responsible disclosure dan embargo telah rusak, tidak ada patch yang tersedia di distribusi mana pun
  • Sebagai mitigasi sementara, disediakan perintah untuk menghapus modul yang memicu kerentanan: 
    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"
    • Mendaftarkan modul esp4, esp6, dan rxrpc sebagai blacklist di /etc/modprobe.d/dirtyfrag.conf lalu melakukan unload
  • Setelah masing-masing distribusi melakukan backport patch, pembaruan tersebut perlu diterapkan

Latar belakang publikasi

  • Setelah berdiskusi dengan para maintainer linux-distros@vs.openwall.org, dokumen Dirty Frag dipublikasikan atas permintaan mereka
  • Embargo telah rusak karena faktor eksternal, dan saat ini belum ada patch maupun CVE
  • PoC dipublikasikan melalui koordinasi dengan linux-distros untuk memberikan informasi yang akurat, dan dilarang digunakan pada sistem tanpa izin

Bacaan terkait

2 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Ini sangat mirip dengan Copy Fail baik dari akar penyebab maupun cara eksploitnya.
    Menurut saya ini contoh yang bagus tentang hal yang mudah hilang ketika terlalu banyak menyerahkan pekerjaan ke LLM, yaitu eksplorasi. Saat meneliti kerentanan dengan AI, terasa kreativitas cukup terhambat. Dalam alur di mana jawaban langsung muncul begitu bertanya, kita jadi tidak melihat apa yang ada di sekeliling. Seperti jin, ia hanya memberi tepat apa yang diminta dan tidak lebih
    Peneliti yang menemukan Copy Fail sangat bergantung pada AI setelah melihat sesuatu yang mencurigakan, tetapi jika ia sendiri membongkar lebih banyak kode, mungkin akan ada lebih banyak peluang menemukan bug kembar seperti ini. Di saat yang sama, kalau prompt-nya dibuat sedikit kurang mengarahkan, LLM terbaru pun tampaknya bisa menemukan bug-bug ini. Ini contoh sinergi negatif yang cukup aneh: bekerja bersama tetapi hasilnya justru menurun

    • Kalau saya tidak salah baca, ini bukan sekadar mirip tetapi akar penyebabnya sama. Ini masalah 32 bit atas Extended ESN pada IPsec == modul/mode kripto authencesn
      pada copy.fail yang diperbaiki justru hal yang salah, dan orang-orang terlalu cepat menyalahkan AF_ALG
      [edit: benar, ini masalah authencesn yang sama. Di kode https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... authencesn hanya muncul di komentar, tetapi tetap masalah yang sama]
      [edit2: masalah RxRPC itu terpisah, yang dimaksud di sini adalah sisi ESP]
    • Bisa juga memakai prompt lanjutan seperti “tolong cari bug dengan jenis serupa”. Setelah contoh nyata sudah tersusun, mencari bug serupa sebenarnya tidak terlalu sulit
      Saya paham soal kreativitas. Seperti alat apa pun, AI bisa mempersempit pandangan. Sulit memakainya hanya sebagai pendamping tanpa menyerahkan seluruh alur kerja
    • Saya tidak mengerti. Sejak awal, yang menemukan bug-bug ini adalah LLM. Tetapi dari penemuan itu, kesimpulannya malah terlihat seperti sinyal bahwa LLM buruk untuk menemukan kerentanan
    • Saya penasaran apakah ini pernyataan yang didukung bukti, atau cuma improvisasi sesaat
    • Sulit sekali menjadikan kerentanan mendasar yang mirip dengan temuan AI tetapi tidak sepenuhnya sama sebagai pelajaran bahwa AI tidak bisa mengeksplorasi
      Selain jika kedua kerentanan itu diungkap bersamaan sebagai satu paket, saya penasaran dalam situasi kontrafaktual seperti apa ini akan dianggap sebagai “eksplorasi yang cukup baik”

  • “Karena embargo bocor, tidak ada patch atau CVE untuk kerentanan-kerentanan ini”
    Tautan: https://github.com/V4bel/dirtyfrag
    Analisis rinci: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    Bagian pentingnya adalah ini: “Copy Fail adalah motivasi awal riset ini. Secara khusus, xfrm-ESP Page-Cache Write dalam rantai kerentanan Dirty Frag memakai sink yang sama dengan Copy Fail. Namun, ia terpicu terlepas dari apakah modul algif_aead dapat digunakan atau tidak. Dengan kata lain, bahkan pada sistem yang sudah menerapkan mitigasi Copy Fail yang dipublikasikan, yaitu blacklist algif_aead, Linux tetap rentan terhadap Dirty Frag”
    Mitigasinya disebut sebagai berikut, walau saya sendiri belum menguji atau memverifikasinya: “Karena jadwal responsible disclosure dan embargo sudah bocor, tidak ada patch untuk distro mana pun. Hapus modul pemicu kerentanan dengan perintah berikut”
    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"
    Dalam pembahasan mitigasi disebutkan bahwa reboot mungkin diperlukan, atau pada mesin yang sudah dieksploitasi, setelah perintah di atas harus menjalankan: sudo echo 3 > /prox/sys/vm/drop_caches

    • Pada sudo echo 3 > /prox/sys/vm/drop_caches, sudo tidak ada efeknya. sudo hanya menjalankan echo, bukan penulisan aktualnya
      Dan kalau mesin sudah dieksploitasi, itu sudah terlambat. Apa pun di dalam disk bisa saja sudah rusak, jadi seluruh image disk harus dibangun ulang
    • Dari shell non-sudo, sudo echo dan redirection tidak bisa dipakai seperti itu
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      atau
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      Dan typo /proc juga sudah saya perbaiki
    • Sebagai catatan, mitigasi juga bisa dilakukan dengan echo 1 > .... Tidak perlu mengosongkan semuanya, cukup hapus page cache dengan 1
      Saya uji lokal di Ubuntu 26.04: saya menjalankan exploit dan mendapat root, memasang mitigasi, lalu menjalankan lagi su tanpa argumen dan langsung jadi root tanpa kata sandi. Setelah page cache dibersihkan, su kembali meminta kata sandi

  • Kita butuh cara mudah untuk memastikan hanya modul kernel yang ada di whitelist yang bisa dimuat. Saya lelah terus memasukkan modul yang bahkan tidak diperlukan ke blacklist

  • Saya tanya lagi, kenapa di copy.fail yang kena semua tuduhan itu algif_aead? Yang bodoh itu authencesn
    authencesn tidak diperbaiki, dan sekarang inilah akibatnya. Ternyata lewat soket jaringan biasa pun bisa mengakses penulisan di luar batas yang sama, atau mungkin memang yang sama persis
    Seharusnya ini terpikirkan, tetapi ternyata tidak
    [edit: yang saya maksud adalah masalah lewat ESP. Masalah RxRPC, setahu saya, sepenuhnya terpisah]

  • Kalau ini benar-benar bekerja di semua distro besar, saya terus dibuat heran oleh betapa tidak bertanggung jawabnya para maintainer. Kenapa fitur kernel opsional yang mungkin berguna bagi kurang dari 0,1% pengguna justru aktif secara default?
    Rasanya seperti praktik distro Linux tahun 1999 yang mengirim instalasi default dengan puluhan layanan jaringan terbuka ke internet. Padahal sekarang bukan 1999

    • Meminta maintainer distro mem-blacklist fitur tertentu karena menilai “kamu tidak akan membutuhkannya (YAGNI)” adalah tuntutan yang cukup besar. Mereka tidak tahu siapa memakai apa. Pengguna selalu bisa kembali dan menyesuaikan build dengan apa yang benar-benar mereka inginkan
      Saya ingat masa awal Linux dulu saat menjalankan make menuconfig untuk memilih persis fitur yang diinginkan di kernel. Jujur saja, saya tidak ingin kembali ke masa itu
      Meski begitu, target yang mudah diperbaiki di sini adalah RHEL. RHEL tidak menjadikan banyak hal sebagai modul yang bisa dimuat, tetapi langsung mengompilasinya ke dalam kernel, sehingga mitigasi seperti copy fail tidak mungkin dilakukan. Mungkin bagian-bagian seperti itu bisa sedikit dikurangi
    • Tidak ada cara untuk menonaktifkan komponen yang mungkin tidak dipakai pengguna tanpa membuat sistem jauh lebih sulit digunakan. Saya sendiri sudah 25 tahun memakai OS bodoh ini dan tetap tidak tahu apa yang harus dinyalakan atau dimatikan untuk melakukan sesuatu
      Maintainer distro Linux adalah maintainer perangkat lunak paling bertanggung jawab di planet ini. Praktik keamanannya jauh lebih baik daripada package manager bahasa pemrograman yang bodoh, mereka memelihara daftar paket yang dikurasi, meninjau perubahan, menambal bug, menyelesaikan masalah packaging yang rumit, melakukan backport perbaikan, memakai rilis bertahap, mendistribusikan file lewat mirror di seluruh dunia, dan memverifikasi semua file secara kriptografis. Dan jangan lupa semua itu mereka lakukan gratis
    • Itu tidak aktif secara default. Itu adalah modul opsional yang dimuat saat dibutuhkan. Seluruh arsitektur kernel memang dirancang agar fungsi inti yang dibutuhkan pengguna dikompilasi masuk, sementara hampir semua hal lain disediakan sebagai modul yang dimuat saat perlu
    • Dalam banyak hal, komputer non-mobile masih tertinggal di tahun 1999. Android jauh lebih muda dan punya kesempatan mengintegrasikan mandatory access control ke seluruh stack, sehingga jauh lebih aman daripada sistem Linux lain
    • Untuk mengeksploitasi ini, penyerang harus bisa mengakses komputer secara langsung. Bisa berupa perangkat USB berbahaya, serangan rantai pasok, atau eksploit terhadap perangkat lunak yang diketahui akan dipasang pengguna, baik secara sengaja maupun otomatis. Lebih jauh lagi, penyerang pada dasarnya harus bisa menjalankan perintah terminal sewenang-wenang, yang dari sisi isolasi perangkat lunak itu sendiri sudah merupakan kompromi besar
      Kalau penyerang sudah bisa melakukan semua itu, kondisinya memang sudah buruk. Naik hak akses menjadi root lewat ini hanyalah masalah kecil pada titik tersebut
      Seperti yang diposting orang lain di bawah: https://xkcd.com/1200/
      Sebelum panik, orang-orang perlu memahami dulu sebenarnya kerentanan ini itu apa

  • Setelah sekian lama, akhirnya kita sampai juga pada kondisi “dengan cukup banyak mata, semua bug itu dangkal”, dan rasanya tidak enak. Mulai sekarang apakah kita harus melakukan pembaruan kernel beberapa kali seminggu?

    • Maksudmu seseorang akan membobol rumahmu, entah bagaimana menemukan kredensial default, lalu bahkan mendapatkan akses root?

  • Saya penasaran bagaimana embargo ini bocor. Apakah ada kebocoran, atau pihak ketiga menemukannya secara independen?

    • Sejak awal sebenarnya embargo itu tidak ada, dan memang tidak mungkin ada
      Linux itu open source, jadi semua patch yang memperbaiki bug keamanan langsung terlihat oleh semua orang. Dengan cara kerja pengembangan kernel, tidak ada cara untuk menghindarinya. Yang orang sebut “embargo” itu adalah gagasan agak bodoh bahwa jika deskripsi patch tidak secara terang-terangan menulis “THIS IS A LPE” dan semua orang tutup mulut, maka kita bisa pura-pura kerentanannya belum bocor sampai pesan “resmi” dikirim ke mailing list
      Dulu pendekatan ini mungkin masih bisa sedikit dibela, tetapi di era LLM, diff dari mailing list bisa dimasukkan ke pipeline otomatis ke model terbaru untuk mengidentifikasi apakah itu patch yang memperbaiki isu keamanan, sehingga pendekatan ini bukan hanya bodoh tetapi juga berbahaya
    • Tautan patch sempat diposting ke akun X seseorang, lalu orang lain melihatnya dan mempublikasikan exploit yang berfungsi dalam waktu kurang dari satu jam. Mungkin eksploitasinya dibantu LLM, tetapi selain waktu perputaran yang cepat, itu bukan klaim yang terbukti
      https://x.com/encrypted_past/status/2052409822998392962
    • Diposting secara publik oleh pihak ketiga yang tidak terkait

  • Ada yang tahu apakah Debian rentan? Saya mencoba exploit pada mesin Debian 12 dan Debian 13, tetapi tidak berhasil mereproduksinya sendiri

    • Saya berhasil mereproduksinya di kernel 6.12.57+deb13-amd64 milik Debian 13, yaitu Trixie, tetapi tidak di kernel 6.1.0-42-amd64 milik Debian 12 Bookworm
      Bagi orang di Bookworm yang tidak memakai security stream paket Debian, kernel 6.1.0-42-amd64 ternyata memang kebal terhadap copy.fail. Mengejutkan bahwa ia juga tampak kebal terhadap dirtyfrag. Jika security stream belum menambalnya, Anda bisa memilih versi kernel yang masih mempertahankan commit 2b8bbc64b5c2. Saya menduga commit yang sama juga mungkin secara tidak sengaja membuat beberapa versi kernel Debian 12 aman dari dirtyfrag
    • Saya baru saja mencoba exploit pada droplet Debian 13 baru di DigitalOcean, dan berhasil
    • Saya mengujinya pada Debian 13 yang sepenuhnya mutakhir dan exploit-nya berjalan. Saya juga mengonfirmasi mitigasinya berfungsi

  • Menjalankannya dari kontainer ubuntu:latest sebagai pengguna default baru
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    Hasil: dirtyfrag: failed (rc=3)
    Kabar baik!

    • Saya juga mendapat hasil yang sama saat menjalankannya di dalam kontainer, tetapi ketika dijalankan langsung di host saya mendapatkan shell. Ini hanya menunjukkan bahwa exploit tersebut tidak berjalan di dalam kontainer. Jadi bisa saja kontainernya tidak rentan, atau skripnya perlu disesuaikan agar bekerja di dalam kontainer
      copy fail bisa dipakai untuk container escape (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), jadi saya menduga exploit ini juga hanya butuh sedikit perubahan
    • Sulit menganggap kontainer sebagai platform yang andal untuk pengujian seperti ini. Baik itu normal maupun tidak, banyak hal memang gagal di dalam kontainer
 
GN⁺ 2 jam lalu
Komentar Lobste.rs

  • Benar-benar minggu yang luar biasa untuk mengelola server Linux bersama. Meski begitu, saya suka karena pengungkapan kali ini langsung menjelaskan inti masalahnya
    Tapi saya tidak paham kenapa semua orang menyembunyikan stderr dalam panduan mitigasi
    Edit: ini katanya dilaporkan pada 30 April dengan “inspirasi” dari copy.fail, jadi ditemukan bahkan belum sampai sehari kemudian? Mengesankan
    Sebagai orang yang punya hak sudo di server bersama yang cukup besar, saya juga penasaran apakah mengompilasi kernel sendiri dengan menyertakan modul sesedikit mungkin adalah ide yang bagus. Saya belum benar-benar menimbang plus minusnya secara mendalam, tetapi rasanya itu mungkin bisa menghindari dua kerentanan eskalasi hak akses lokal minggu ini
    Edit 2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    Oh, yang ini tidak butuh setuid. Senang ini disertakan

    • Saya melakukan itu di sistem multi-pengguna yang saya kelola, dan memang berhasil menghindari dua eksploit root lokal minggu ini

  • Apakah memungkinkan dan masuk akal untuk mengambil daftar modul kernel yang dimuat pada sistem yang sedang berjalan lalu menetapkannya sebagai allowlist modprobe untuk sistem itu?
    Baik CopyFail maupun DirtyFrag tampaknya mengeksploitasi modul kernel yang tidak dimuat di sistem mana pun yang saya periksa. Kalau begitu, memblokir modul yang jelas-jelas tampak tidak diperlukan mungkin bisa memitigasi sebagian serangan lebih awal, bukan?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    Saya tidak mengerti bagaimana hal seperti ini bisa dibiarkan. Rasanya benar-benar tidak masuk akal bahwa informasi sebesar ini berada di lingkungan yang sulit dipercaya seperti itu

    • Saya tidak yakin apakah yang dimaksud “dipublikasikan oleh pihak ketiga yang tidak terkait” adalah kasus ini, tetapi sebagai referensi, Brad Spengler melihat commit perbaikannya lebih dulu lalu menyadari kerentanan keamanan yang diisyaratkan oleh pesan commit, dan di balasannya seseorang membuat exploit dengan vibe coding
      Pihak ketiga mana pun yang memantau commit Linux mungkin saja menangkap petunjuk yang sama dan membuat exploit
    • Ungkapan “pihak ketiga yang tidak terkait” terdengar seperti berarti mereka tidak tahu bahwa bug itu sedang dalam embargo
      “Lingkungan yang sulit dipercaya” di sini adalah seluruh internet, dan pada praktiknya hampir tidak ada yang bisa disebut benar-benar terisolasi. Dulu memang sudah begitu, sekarang hanya makin jelas. Tulisan terbaru Stefan Eissing tentang bug Apache httpd yang ditemukan ulang dua kali sebelum diperbaiki juga layak dibaca

  • Apakah ada cara untuk menguji apakah modul yang terdampak benar-benar tidak bisa dimuat?
    Saat CopyFail, saya sempat salah saat pertama menerapkan mitigasi. Nama file di /etc/modprobe.d/ tidak diakhiri dengan .conf, dan saya tidak menyadarinya sampai menjalankan perintah pengujian dari https://news.ycombinator.com/item?id=47954159. Apakah ada perintah serupa untuk modul esp4/esp6/rxrpc?

    • Saya sudah mencoba memuat ketiga modul itu dengan modprobe dan muncul error yang sama seperti sebelumnya
      Ada juga kode proof-of-concept yang dilampirkan, tetapi saya belum mencobanya