Copy Fail – CVE-2026-31431

 (copy.fail)
4 poin oleh GN⁺ 7 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Pengguna lokal tanpa hak istimewa dapat menggabungkan authencesn, AF_ALG, dan splice() untuk membuat penulisan 4 byte ke page cache pada file yang dapat dibaca, lalu memanfaatkannya untuk meningkatkan hak akses hingga root
  • Tanpa offset spesifik kernel atau kondisi race, cukup dengan satu skrip Python 732 byte yang berjalan apa adanya di berbagai distribusi Linux, dan eksploit yang sama dapat memperoleh root shell
  • Cakupan dampaknya mencakup sebagian besar distribusi Linux utama sebelum patch diterapkan, dan karena AF_ALG aktif pada konfigurasi default, eksposurnya luas dari 2017 hingga waktu patch dirilis
  • Pada host multi-tenant, klaster Kubernetes / container, runner CI, dan Cloud SaaS yang mengeksekusi kode pengguna, satu akun biasa atau satu pod dapat berujung pada root host sehingga patch perlu diprioritaskan
  • Respons utamanya adalah patch kernel yang mencakup commit mainline a664bf3d603d, dan sebelum patch diterapkan, penting untuk menonaktifkan algif_aead serta memblokir AF_ALG untuk workload yang tidak tepercaya

Ringkasan kerentanan

  • Satu cacat logika linear dapat dirangkai melalui authencesn, AF_ALG, dan splice() hingga menjadi penulisan 4 byte ke page cache, yang memungkinkan peningkatan hak akses lokal
  • Tanpa offset spesifik kernel atau race window, cukup satu skrip Python 732 byte yang bekerja identik di berbagai distribusi Linux yang dirilis sejak 2017
  • Biner eksploit yang sama dapat memperoleh root shell di berbagai distribusi tanpa modifikasi
  • Cukup memiliki akun lokal tanpa hak istimewa; tidak diperlukan akses jaringan, fitur debugging kernel, atau primitive lain yang sudah terpasang sebelumnya

Cakupan dampak

  • Sebagian besar distribusi Linux utama yang menggunakan kernel sebelum patch termasuk dalam cakupan
  • Pada konfigurasi default, AF_ALG milik API kriptografi kernel pada praktiknya aktif di hampir semua distribusi mainstream, sehingga langsung terekspos dari 2017 hingga waktu patch dirilis
  • Distribusi yang telah diverifikasi secara langsung adalah Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3, dan SUSE 16
  • Debian, Arch, Fedora, Rocky, Alma, Oracle, dan lini embedded juga akan terdampak jika menggunakan kernel yang rentan

Lingkungan yang perlu dipatch lebih dulu

  • Pada host Linux multi-tenant, banyak pengguna berbagi kernel yang sama, sehingga akun pengguna mana pun dapat langsung menjadi root
  • Pada klaster Kubernetes / container, page cache dibagikan ke seluruh host sehingga satu pod dapat mengambil alih node dan melampaui batas tenant
  • Pada runner CI dan build farm, kode PR tidak tepercaya yang dijalankan dengan hak pengguna biasa dapat menjadi root di runner
  • Pada Cloud SaaS yang mengeksekusi kode pengguna, container atau skrip yang diunggah tenant dapat berujung pada root host
  • Server single-tenant lebih bersifat LPE internal dan bisa digabungkan dengan web RCE atau kredensial yang dicuri
  • Laptop dan workstation pengguna tunggal memiliki urgensi lebih rendah, tetapi eksekusi kode lokal tetap dapat langsung berujung pada eskalasi ke root

PoC yang dipublikasikan dan cara penggunaannya

  • PoC dipublikasikan agar pihak defensif dapat memanfaatkannya untuk memverifikasi sistem dan memastikan patch vendor
  • copy_fail_exp.py hanya menggunakan library standar Python 3.10+ yaitu os, socket, dan zlib
  • Target default-nya adalah /usr/bin/su, dan biner setuid lain dapat diberikan melalui argv[1]
  • Ia memodifikasi biner setuid di dalam page cache; perubahan tidak bertahan setelah reboot, tetapi root shell yang diperoleh benar-benar berfungsi
  • Issue tracker

Mitigasi

  • Yang paling utama adalah patch kernel, dan kernel distribusi harus diperbarui ke versi yang mencakup commit mainline a664bf3d603d
  • Patch ini membalikkan optimisasi in-place pada algif_aead yang diperkenalkan pada 2017, sehingga halaman page cache tidak masuk ke writable destination scatterlist
  • Sebelum patch diterapkan, disarankan untuk menonaktifkan modul algif_aead
    • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
    • rmmod algif_aead 2>/dev/null || true
  • Pada container, sandbox, dan CI yang menjalankan workload tidak tepercaya, terlepas dari status patch, perlu memblokir pembuatan socket AF_ALG dengan seccomp

Dampak saat dinonaktifkan

  • Pada sebagian besar sistem, hampir tidak ada dampak yang terukur
  • dm-crypt / LUKS, kTLS, IPsec/XFRM, in-kernel TLS, build default OpenSSL/GnuTLS/NSS, SSH, dan crypto kernel keyring tidak terdampak
    • Mereka menggunakan API kriptografi kernel secara langsung dan tidak melewati jalur AF_ALG
  • Jika engine afalg di OpenSSL diaktifkan secara eksplisit, beberapa jalur offload kriptografi embedded, atau aplikasi yang langsung melakukan bind ke socket aead/skcipher/hash, dapat terdampak
    • Dapat diperiksa dengan lsof | grep AF_ALG atau ss -xa
  • Menonaktifkan AF_ALG tidak akan memperlambat target yang sejak awal tidak memanggilnya, sedangkan target yang menggunakannya akan kembali ke library kriptografi userspace biasa

Perbedaannya dengan Linux LPE pada umumnya

  • Berbeda dari LPE Linux pada umumnya, tidak ada kondisi race dan tidak memerlukan offset khusus per distribusi
  • Keandalannya juga diklaim 100% sekali jalan, dan cakupannya bukan rentang versi kernel yang sempit, melainkan periode panjang dari 2017 hingga 2026
  • Karena ukurannya hanya 732 byte dan hanya memakai library standar Python, tidak ada payload terkompilasi atau dependensi terpisah
  • Jalur penulisannya melewati VFS, dan halaman yang rusak tidak ditandai dirty sehingga tidak ada apa pun yang ditulis ke disk
  • Karena page cache dibagikan ke seluruh host, ini bukan sekadar LPE melainkan juga dapat berfungsi sebagai primitive container escape

Cara kerja dan karakteristik deteksi

  • Pengguna lokal tanpa hak istimewa dapat menulis 4 byte yang dapat dikendalikan ke page cache file yang dapat dibaca pada sistem Linux, lalu memanfaatkannya untuk memperoleh root
  • Targetnya bukan file aktual di disk, melainkan page cache di memori; jika salinan cache dari /usr/bin/su diubah, dari sudut pandang execve itu sama saja dengan mengubah binernya sendiri
  • Karena tidak ada perubahan di disk, inotify tidak akan terpicu, dan setelah reboot atau cache ter-evict, file asli akan dimuat kembali
  • Alat hash umum seperti sha256sum, AIDE, dan Tripwire membaca page cache melalui read(), sehingga selama kerusakan masih berada di cache, hasil hash bisa berbeda dari baseline
  • Setelah cache ter-evict atau sistem reboot, hash akan kembali cocok seperti semula, dan citra forensik disk juga hanya akan menyisakan file yang tidak dimodifikasi
  • Dalam IMA appraisal enforcing mode, jika every-read measurement aktif, biner yang rusak dapat terdeteksi pada saat execve sebelum dijalankan

Perbedaan dengan kerentanan lain

  • Ini sekeluarga dengan Dirty Pipe, karena sama-sama merusak page cache dari userspace tanpa hak istimewa dan memperoleh root dengan menulis ke biner setuid tanpa perubahan di disk
  • Mekanismenya berbeda: Dirty Pipe menyalahgunakan pipe buffer flags, sedangkan Copy Fail menyalahgunakan AEAD scratch write yang melintasi batas chained scatterlist
  • Dirty Pipe memerlukan kernel 5.8+ dengan patch tertentu, sedangkan Copy Fail mencakup jendela dari 2017 hingga 2026
  • Tidak seperti Dirty Cow, tidak perlu memenangkan race COW berbasis TOCTOU, mencoba berulang kali, atau membuat sistem tidak stabil

Detail tambahan

  • /usr/bin/su tidak wajib; selama itu adalah biner setuid-root yang dapat dibaca pengguna, passwd, chsh, chfn, mount, sudo, dan pkexec juga bisa digunakan
  • Ini bukan kerentanan jarak jauh; terlebih dahulu dibutuhkan eksekusi kode lokal dengan hak pengguna biasa
  • Jika web RCE jatuh ke akun layanan tanpa hak istimewa, atau digabungkan dengan foothold SSH maupun PR berbahaya di runner CI, hal itu dapat berujung pada root
  • Patch tersebut membalikkan optimisasi in-place pada algif_aead sehingga req->src dan req->dst kembali menjadi scatterlist yang terpisah
  • Halaman page cache hanya tersisa pada source yang read-only, dan target yang bisa ditulisi oleh proses kriptografi tinggal buffer pengguna

Jadwal publikasi dan materi lanjutan

  • 2026-03-23 dilaporkan ke tim keamanan kernel Linux
  • 2026-03-24 konfirmasi awal dilakukan
  • 2026-03-25 patch diusulkan dan ditinjau
  • 2026-04-01 patch di-commit ke mainline
  • 2026-04-22 CVE-2026-31431 dialokasikan
  • 2026-04-29 dipublikasikan di https://copy.fail/
  • Analisis teknis blog Xint
    • Memuat root cause, diagram scatterlist, kronologi 2011→2015→2017, dan walkthrough eksploit
    • Part 2 yang membahas container escape Kubernetes dijadwalkan dipublikasikan kemudian

Informasi terkait Xint Code

  • Ditemukan dengan pendekatan AI-assisted, dengan titik awal berupa penelitian manusia bahwa splice() menyerahkan halaman page cache ke crypto subsystem dan bahwa asal halaman dalam scatterlist bisa menjadi kelas bug yang kurang dieksplorasi
  • Setelah itu, Xint Code memperluas audit ke seluruh subsystem Linux crypto/ dalam skala sekitar 1 jam, dan dari hasil tersebut temuan paling parah adalah Copy Fail
  • Xint Code
    • Tulisan blog Xint
    • Bug berisiko tinggi lain juga ditemukan dalam pemindaian yang sama, dan saat ini masih dalam proses coordinated disclosure

Bacaan terkait

1 komentar

 
GN⁺ 7 jam lalu
Pendapat Hacker News

  • Dari sudut pandang orang yang menangani kode crypto kernel Linux, eksploit AF_ALG yang meledak secara berkala ini benar-benar menjengkelkan
    AF_ALG sudah lama masuk ke kernel tanpa review yang memadai, strukturnya terlalu rumit, dan membuka permukaan serangan yang sangat besar ke program userspace non-privileged
    Selain itu, nyaris tidak diperlukan. Userspace sudah punya kode kriptonya sendiri, dan kode crypto kernel pada awalnya memang ditujukan untuk penggunaan internal kernel seperti dm-crypt
    authencesn pada eksploit kali ini juga pada dasarnya adalah detail implementasi internal IPsec, jadi menurut saya sejak awal sudah keliru mengekspos ini sebagai API enkripsi/dekripsi userspace umum
    Jika Anda mengelola konfigurasi kernel Linux, saya sangat menyarankan mematikan semua opsi CONFIG_CRYPTO_USER_API_*
    Hanya dengan itu saja, bukan cuma bug kali ini, tetapi banyak bug AF_ALG di masa lalu dan masa depan juga akan menjadi tidak bisa dieksploitasi
    Kalau ada program userspace yang rusak karenanya, pendekatan yang tepat adalah membantu memindahkannya ke kode crypto userspace, dan pada kenyataannya memang ada yang sudah berubah ke arah itu
    Dari awal, AF_ALG memang tidak banyak gunanya selain untuk eksploit
    Dulu API userspace seperti ini mungkin masih agak bisa ditoleransi, tetapi sekarang dengan adanya syzbot dan deteksi bug berbantuan LLM, ini rasanya sudah tidak bisa dipertahankan lagi

    • Saya tidak tahu apa itu AF_ALG, jadi saya cari dan menemukan https://www.chronox.de/libkcapi/html/ch01s02.html, dan di sana memang tertulis alasan keberadaannya
      Alasan yang diajukan adalah memungkinkan akselerator perangkat keras yang hanya bisa diakses dalam mode kernel digunakan dari userspace, memungkinkan kunci diserahkan ke kernel tanpa lama tinggal di memori aplikasi, dan bisa mengurangi footprint dibanding library crypto userspace di lingkungan dengan memori terbatas seperti embedded
      Saya tidak bisa menilai apakah itu pembenaran yang cukup kuat, tetapi setidaknya memang ada alasannya
    • Saya penasaran bagaimana ini bisa masuk ke kernel
      Linus dikenal cukup selektif soal apa yang boleh masuk ke kernel, jadi latar belakang masuknya API seperti ini sepertinya akan jadi cerita yang menarik
    • AF_ALG adalah antarmuka socket Linux yang mengekspos API crypto kernel sebagai file descriptor
      Ini memungkinkan hash dan enkripsi ditangani lewat pemanggilan read(2)/write(2) biasa
    • Yang paling saya penasaran adalah perangkat lunak apa yang akan rusak kalau opsi kernel ini dimatikan

  • Sepertinya ada kebingungan dalam proses pengungkapannya
    Vendor tampaknya tidak menangani kerentanan ini dengan cukup serius, sehingga di banyak distro statusnya masih belum dipatch
    https://access.redhat.com/security/cve/cve-2026-31431 menuliskannya sebagai "Moderate severity", "Fix deferred", dan halaman pelacakan Debian, Ubuntu, serta SUSE juga terlihat mirip

    • Sejak patch masuk ke kernel, praktis ini sudah diketahui oleh penyerang atau pengamat selama beberapa minggu
      Namun upstream tidak mengomunikasikan ini secara jelas sebagai sebuah kerentanan, dan Linus maupun Greg memang cenderung tidak terlalu menganggap penting klasifikasi seperti itu di kernel
    • Alasan distro menilainya sebagai risiko sedang tampaknya karena ini bukan remote code execution, melainkan memerlukan akses lokal
      Meski begitu, karena ini memungkinkan eskalasi hak akses ke root dari lokal, secara umum rasanya tetap layak dianggap prioritas tinggi
      https://ubuntu.com/security/cves/about#priority
    • RedHat sekarang sudah mengubahnya menjadi Important severity dan Affected
    • Kalau melihat panduan Ubuntu sendiri, ini tampaknya semestinya masuk high priority, tetapi label yang dipakai medium, jadi terasa tidak konsisten

  • Agak disayangkan karena tidak langsung tertulis di artikel utama versi kernel mana yang rentan dan di versi mana sudah dipatch
    Terutama karena ini modul builtin sehingga tidak mudah dicabut dengan rmmod
    Saat mencari tahu apakah kernel 6.19.14 di Fedora 44 rentan, saya menemukan posting mailing list linux-cve-announce https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    Di sana tertulis bahwa ini diperbaiki oleh commit terkait masing-masing di 6.18.22, 6.19.12, dan 7.0, jadi itu cukup membantu sebagai referensi

  • Jika ingin memeriksa apakah modul kernel algif_aead benar-benar diblok lewat konfigurasi modprobe sesuai mitigasi yang direkomendasikan, tidak perlu menjalankan shell code yang diobfuscate bulat-bulat
    Dengan beberapa baris Python seperti di bawah ini, Anda bisa mengecek secara lebih mudah dibaca apakah modulnya benar-benar termuat
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    Jika mitigasinya diterapkan dengan benar, modprobe algif_aead juga seharusnya gagal dengan error

  • Tentu tidak ada orang yang menjalankan agen AI otonom penuh dengan hak pengguna biasa pada sistem operasi yang terdampak
    Jika digabungkan dengan prompt injection zero-day, ini bisa jadi cukup katastrofik

    • Agen saya malah sudah berjalan sebagai root, jadi saya tidak akan melihat masalah itu
    • Syukurlah kita tidak menjadikan instalasi lewat curl | sh sebagai standar industri

  • LPE berarti local privilege escalation
    Singkatan di bidang keamanan terlalu banyak, dan meskipun bisa ditebak dari konteks, tetap saja sebaiknya ditulis lengkap saat pertama kali muncul

    • LPE adalah singkatan yang cukup dikenal luas di komunitas keamanan, jadi saya tidak menganggap ini kesalahan besar
      Tetapi saya setuju bahwa untuk tulisan yang ditujukan ke pembaca yang lebih luas, lebih baik didefinisikan secara eksplisit
      Apalagi keseluruhan artikel ini juga terlihat seperti hasil generasi AI
    • Untuk tulisan yang ditujukan ke audiens luas, menuliskan kepanjangan singkatan lebih dulu adalah hal mendasar, dan LLM cenderung kurang patuh pada panduan semacam itu

  • Ini agak lucu
    Halamannya menulis bahwa ini bekerja di RHEL 14.3, padahal versi seperti itu tidak ada
    Saat ini RHEL masih 10.x, jadi rasanya seperti naik TARDIS

    • 14.3 tampaknya bukan versi RHEL, melainkan berasal dari penomoran versi GCC di pihak Red Hat
      Kadang muncul seperti gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2), dan jejak serupa juga terlihat pada contoh-contoh di bawah ini
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • Di baris yang sama juga tertulis 6.12.0-124.45.1.el10_1, dan itu jelas kernel RHEL 10
      Salah ketik seperti ini justru lebih sering dilakukan manusia
      Angka panjang hasil copy-paste akurat, tetapi angka yang mudah malah salah karena diketik manual
    • Maaf, tetapi itu akan diperbaiki
      Ada proses pengumpulan informasi secara terburu-buru untuk menjelaskan isu ini, dan ya, memang ada unsur pemasaran juga
      Jadi ada beberapa kesalahan kecil yang ikut masuk, dan saya rasa wajar untuk berterima kasih karena itu ditunjukkan
    • Betul, saat melihat frasa "Distribusi yang diverifikasi langsung: RHEL 14.3", setidaknya halaman rilisnya langsung terasa seperti AI slop
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      Setelah melihat bagian "Talk to our security experts" di bagian bawah halaman, saya jadi merasa jangan-jangan nama ahli keamanannya Claude

  • Di RHEL 9/10, algif_aead bukan modul melainkan builtin, jadi tidak bisa di-unload
    Karena itu saya mencari cara memblokir AF_ALG lewat systemd sebagai opsi terbaik berikutnya, dan diperlukan drop-in untuk tiap layanan yang terekspos
    Ada juga playbook Ansible yang biasanya menangani sshd dan user@ yang paling penting
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • Di RHEL 9/10 juga dimungkinkan menambahkan initcall_blacklist=algif_aead_init ke opsi boot kernel lalu reboot
      Setelah itu, eksploitnya tidak lagi berjalan
    • Saya juga memikirkan arah serupa, tetapi memblokir per layanan terasa seperti main pukul tikus mondok
      Saya khawatir dengan jalur eksekusi lain seperti cronjob dan slurmjob, dan akan bagus kalau ada cara agar semua proses mewarisinya secara global di level systemd, alih-alih harus ditambahkan ke tiap layanan satu per satu

  • Eksploit ini tampaknya bekerja dengan menukar biner SUID agar dijalankan sebagai PID 0
    Namun situsnya mengklaim ini juga bisa kabur dari Kubernetes / container clusters dan CI runners & build farms, sementara saya tidak melihat penjelasan yang benar-benar mendukung skenario kabur dari kontainer, terutama user namespace escape
    Saat saya coba di rootless Podman, seperti dugaan, saya tetap tidak bisa keluar dari kontainer
    Mereka juga mengklaim bisa "menjadikan root semua distribusi Linux yang dirilis sejak 2017", tetapi pengujian nyatanya hanya empat, dan di Alpine itu tidak bekerja

    • Pihak situs juga bilang penjelasan rinci akan segera dipublikasikan, jadi mungkin ada langkah tambahan atau revisi di part 2
      Mereka sudah memberi teaser: "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
    • Kerentanan ini memungkinkan penimpaan byte memori dari file yang bisa dibaca, jadi cukup mudah membayangkan bagaimana ini bisa dipakai untuk keluar dari berbagai lingkungan
    • Klaim semua distro sejak 2017 tampaknya didasarkan pada fakta bahwa kerentanan ini masuk lewat commit pada paruh kedua 2017
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      Namun kemungkinan bisa dieksploitasi dalam praktik akan berbeda tergantung apakah itu rilis mayor terbaru atau kernel maintenance pada cabang lama
    • Artikel ini cukup merusak kredibilitasnya sendiri
      Meski begitu, setelah saya menjalankan PoC langsung di instance 24.04, kerentanannya tampak nyata dan memang terlihat seperti isu besar
      Hanya saja jumlah distro yang terdampak tampaknya jauh lebih sedikit daripada yang diklaim, dan cukup jauh dari pernyataan semua distro sejak 2017
      Misalnya, kalau interpretasi saya benar, Ubuntu bahkan sedikit terdampak di 16.04 EOL, dan dampak utama yang nyata tampaknya lebih ke kernel vendor yang baru mulai didistribusikan belakangan, seperti seri 6.17 semacam linux-gcp dan linux-oracle-6.7
    • Bahkan dari dalam kontainer rootless, kalau bisa naik sampai UID 0 yang nyata, langkah keluar berikutnya mungkin saja dilakukan
      Hanya saja akan butuh tahap tambahan, dan Alpine pun mungkin tetap memiliki kerentanan dasarnya, hanya skripnya saja yang perlu disesuaikan
      Pada akhirnya ini bukan eksploit universal yang sudah matang, melainkan PoC

  • Halamannya sendiri memang terasa agak vibecoded dan seperti iklan, tetapi kerentanannya nyata dan tingkat bahayanya tampak tinggi
    Ini menjelaskan kenapa hari ini ada pembaruan keamanan besar, jadi saya harus menaikkan prioritas update

    • Ini memang iklan yang cukup terang-terangan, tetapi secara pribadi saya tidak menganggapnya buruk
      Mereka menemukan bug nyata, membantu mem-patch-nya, sehingga memberi kontribusi yang berarti bagi ekosistem OSS, sambil sekaligus menjual alat keamanan mereka sendiri
    • Orang-orang ini tampaknya sudah kebanjiran pekerjaan bahkan tanpa perlu iklan
      Hanya saja sekarang ini siapa yang masih membuat halaman web sepenuhnya manual, apalagi kalau pengembang kernel, jadi itu terasa masuk akal