Copy Fail – CVE-2026-31431

 (copy.fail)
9 poin oleh GN⁺ 2026-04-30 | 5 komentar | Bagikan ke WhatsApp
  • Kerentanan eskalasi hak akses dengan pelarian kontainer yang memungkinkan mendapatkan hak akses root di semua distribusi Linux sejak 2017
  • Memanfaatkan cacat logika sederhana yang ada di modul kriptografi kernel Linux (authencesn), dan dapat dijalankan hanya dengan satu skrip Python berukuran 732 byte tanpa perlu sinkronisasi timing yang rumit (race condition) atau penyesuaian per versi kernel
  • Prinsip intinya adalah memanipulasi cache dalam memori (page cache) yang dirujuk Linux saat mengeksekusi file, dengan menghubungkan AF_ALG (socket kriptografi kernel) dan splice() (system call penyalinan data) untuk menimpa 4 byte pada salinan cache dari biner setuid
    • File di disk yang sebenarnya tidak berubah, sehingga ini menjadi serangan senyap yang tidak meninggalkan jejak pada image disk forensik
    • Setelah reboot atau memori dibebaskan, cache kembali ke aslinya, sehingga deteksi pasca-insiden dengan pemeriksaan integritas file tradisional menjadi sulit
  • Karena page cache dibagikan ke seluruh host, dalam lingkungan Kubernetes satu pod yang memanfaatkan kerentanan ini dapat menguasai node host dan melakukan pelarian kontainer hingga menembus kontainer tenant lain
  • Telah diverifikasi langsung pada Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, dan SUSE 16, dan langsung berfungsi hanya dengan akun pengguna lokal tanpa hak istimewa, tanpa akses jaringan atau fitur debugging kernel
  • Kerentanan eskalasi hak akses Linux (LPE) yang ada sebelumnya biasanya hanya memiliki tingkat keberhasilan 30~80% per percobaan dan hanya bekerja pada rentang kernel tertentu, tetapi Copy Fail menargetkan semua distribusi selama 9 tahun (2017~2026) dengan tingkat keberhasilan 100% dalam satu percobaan
  • Berbeda dari Dirty Pipe (penyalahgunaan flag buffer pipe) dan Dirty Cow (memerlukan race timing), yang sama-sama termasuk keluarga manipulasi page cache, Copy Fail jauh lebih sederhana dan kuat karena tidak memerlukan race condition, tidak butuh offset khusus distribusi, dan tidak perlu kompilasi ulang
  • Target paling mendesak: host Linux multi-tenant, klaster Kubernetes/kontainer, runner CI (GitHub Actions self-hosted, GitLab Runner, dll.), cloud SaaS yang mengeksekusi kode pengguna — semua lingkungan tempat kode tak tepercaya berjalan di atas kernel bersama
  • Tindakan paling prioritas adalah patch kernel (commit mainline a664bf3d603d) — membatalkan optimisasi in-place pada modul kriptografi yang diperkenalkan pada 2017 agar halaman page cache tidak ikut menjadi target tulis operasi kriptografi
  • Sebagai mitigasi sementara sebelum patch, modul algif_aead dapat dinonaktifkan, dan tidak berdampak pada fungsi kriptografi umum seperti dm-crypt/LUKS, kTLS, IPsec, dan SSH
  • Pada lingkungan workload tak tepercaya seperti kontainer, sandbox, dan runner CI, terlepas dari status patch, disarankan memblokir pembuatan socket AF_ALG dengan seccomp
  • Taeyang Lee dari Xint memperoleh wawasan awal bahwa "struktur splice() yang menyerahkan halaman page cache ke subsistem kriptografi adalah kelas bug yang belum banyak dieksplorasi", dan Xint Code menjadi contoh deteksi kerentanan berbantuan AI yang menemukan masalah ini dengan memindai subsistem kernel crypto/ secara otomatis dalam waktu sekitar 1 jam

Bacaan terkait

5 komentar

 
popopo 2026-05-04

Sepertinya Rocky Linux masih belum mengeluarkan patch.

RHEL

AlmaLinux

Rocky Linux

Saya sedang menggunakan Rock Linux, dan jika tidak bisa reboot maka pemblokiran dengan bpftool dari https://github.com/wgnet/wg.copyfail.patch efektif.
 
popopo 2026-05-04

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

Patch memang ada, tetapi hanya disediakan di repositori layanan berlangganan. Versi CE tidak mendapatkan patch. (dikonfirmasi pada 9.7, 10.1)
 
popopo 28 hari lalu

Patch dirilis pada 2026-05-05.

Pada 2026-05-10 ada opsi keamanan baru.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

Jika repositori keamanan ditambahkan, tampaknya langkah keamanan bisa dilakukan secara terpisah dari penerapan source RHEL.
 
sukso96100 2026-05-02

Bagi yang menggunakan Ubuntu, sepertinya sudah ada panduan langkah penanganannya, jadi bisa dijadikan referensi.

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
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