Kerentanan kernel Linux tidak memberi pemberitahuan awal ke distro

• CopyFail, kerentanan eskalasi hak akses lokal di kernel Linux, termasuk salah satu kerentanan “make-me-root” (yang membuat pengguna biasa menjadi root) paling serius di kernel dalam beberapa waktu terakhir
• Kerentanan ini diperkenalkan dalam commit tertentu pada kernel versi 4.14, dan bertepatan dengan waktu ditambahkannya optimisasi in-place pada modul authencesn yang dieksploitasi oleh CopyFail
• Perbaikannya telah diterapkan ke kernel 6.18.22, 6.19.12, dan 7.0, dan 6.18.22 serta 6.19.12 dirilis pada 11 April dengan perbaikan yang sudah di-backport (menerapkan patch dari versi yang lebih tinggi ke versi yang lebih rendah)
• Namun, perbaikan tersebut masih belum disertakan di kernel Longterm yang masih banyak digunakan (6.12, 6.6, 6.1, 5.15, 5.10), dan juga belum terlihat di upstream stable queue
  • Karena masalah ini diperkenalkan pada 2017, perlu dipastikan apakah kernel Longterm lama tersebut juga terdampak
• Patch perbaikannya tidak clean apply (dapat diterapkan dengan rapi tanpa konflik kode) ke kernel lama, dan karena beberapa perubahan API, situasinya membuat upaya backport sulit dilakukan dengan keyakinan penuh
• Untuk lingkungan yang membutuhkan respons segera, sebagai langkah sementara dapat diterapkan patch yang menonaktifkan modul authencesn pada IPSec, dan bahkan bagi yang bukan ahli IPSec, ini termasuk pilihan yang “tidak sempurna, tetapi lebih baik daripada alternatif yang lebih buruk”
• Artinya, masalah strukturalnya ada pada proses pengungkapan kerentanan kernel Linux itu sendiri:
  • Kerentanan kernel Linux tidak memiliki mekanisme yang otomatis menyampaikan pemberitahuan awal ke tiap distro kecuali pelapor kerentanan sendiri memberi tahu mailing list linux-distros (kanal tertutup tempat tim keamanan distro berkumpul)
  • Pada kasus CopyFail ini juga tidak ada peringatan awal (heads-up) melalui linux-distros ML
  • Artinya, tim keamanan distro utama seperti Ubuntu, RHEL, dan SUSE tidak mendapat kesempatan menyiapkan patch sebelum kerentanannya dipublikasikan

[unsure4000]

Tulisan blognya memang agak kekanak-kanakan, tetapi saya rasa kelemahan sistemiknya lebih besar sehingga sulit menilai kesalahannya lebih dari sekadar menjengkelkan.

[GN⁺]

Komentar Hacker News

• Sam James, penulis tulisan yang ditautkan, adalah pengembang Gentoo
  Bagaimanapun, ini nyaris seperti bencana, dan merilis exploit sebelum distro sempat mendistribusikan perbaikannya adalah tindakan yang sangat tidak bertanggung jawab
  Tidak jelas berapa banyak penyedia shared hosting yang mungkin diretas gara-gara ini
  Juga mengkhawatirkan bahwa tampaknya tidak ada komunikasi antara kernel security team dan maintainer distro
  Orang mungkin berharap pihak pertama akan memberi tahu pihak kedua, tetapi kenyataannya tampak seperti orang yang menemukan kerentananlah yang harus memikul tanggung jawab itu

  • Saya tidak melihat masalah dengan pengungkapan 30 hari setelah patch masuk kepada pihak yang dilapori
    Sebagai referensi, Google Project Zero juga memakai kebijakan serupa, “90+30”: https://projectzero.google/vulnerability-disclosure-policy.h...
    Masalah yang sebenarnya adalah tidak adanya saluran komunikasi antara kernel security team dan maintainer distro
    Orang yang menemukan kerentanan seharusnya tidak dibebani tanggung jawab untuk melapor secara terpisah ke semua downstream
    Tim kernel seharusnya memberi tahu daftar petugas keamanan distro tentang tingkat pentingnya patch dan jadwal pengungkapan 30 hari kemudian
  • Pengungkapan kali ini terasa lebih dekat ke pemasaran daripada keamanan
    Di halaman pengungkapannya bahkan ada frasa seperti “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]”
    Ini cara yang membuat produk terlihat lebih menarik ketika kekacauan makin besar
  • Sebagai pengguna sekaligus admin, saya tidak setuju bahwa ini “sangat tidak bertanggung jawab”
    Ungkapan Responsible Disclosure adalah istilah yang secara linguistik dirancang dengan baik, seperti “Secure Boot”, dan dalam praktiknya tampak lebih untuk menjaga reputasi organisasi perantara perusahaan/fondasi antara saya dan komputer saya
    Mereka lebih peduli mencegah orang berkata “RHEL rentan”, “Ubuntu rentan” daripada apakah komputer pribadi saya rentan
    Kerentanannya tetap ada bagaimanapun juga, jadi menurut saya lebih baik punya kesempatan mengetahui risikonya dan menguranginya daripada hanya menunggu perbaikan diam-diam masuk
    Dengan kata lain, saya menganggap pengungkapan segera adalah satu-satunya pilihan yang tidak tidak bertanggung jawab
  • Terlepas dari posisi soal prosedur pengungkapan, jika ada hosting provider yang diretas karena ini, pada dasarnya mereka memang sudah berada dalam posisi yang kalah
    Menjalankan workload tenant yang saling tidak percaya di bawah single shared kernel bukanlah ide yang baik
    Kernel LPE bukan hal langka, dan kasus ini hanya sangat sederhana serta mudah dipindahkan, sementara capability mentahnya sendiri nyaris merupakan CNE commodity
  • Linux kernel tidak cocok dipakai sebagai batas keamanan
    Jika ingin melakukan shared hosting tanpa diretas, perlu memakai sarana lain seperti gVisor atau Firecracker VM
    Mungkin Android adalah satu-satunya sistem penting yang memakai ini sebagai batas keamanan, dan itu pun dimitigasi dengan persetujuan pengguna untuk pemasangan APK, kebijakan SELinux dan seccomp yang ketat, serta hardening GrapheneOS
    Dalam kasus ini pun mitigasinya berhasil: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

• Saya tidak mengerti alasan mengatakan hal seperti “untuk kerentanan Linux kernel, distro tidak mendapat pemberitahuan awal kecuali reporter sendiri yang membawanya langsung ke linux-distros ML”
  Mengharapkan reporter untuk berkoordinasi langsung dengan distro mengandaikan tingkat pengetahuan yang sangat tinggi tentang proyek Linux
  Pelapor kerentanan seharusnya tidak bertanggung jawab bekerja langsung dengan semua konsumen downstream Linux kernel
  Kalau begitu, apakah mereka juga harus menghubungi semua produsen perangkat yang memakai Linux di peralatannya?
  Menurut saya, pelapor sudah cukup bertanggung jawab dengan mengungkapkannya ke Linux dan menunggu sampai patch masuk
  Seharusnya ada orang di dalam proyek Linux yang punya wewenang dan tanggung jawab atas kerentanan keamanan, dan merekalah yang harus memberi tahu distro downstream

  • Ini makin berlaku karena reporter secara eksplisit diminta untuk tidak memberi tahu tim distro lebih dulu
    https://docs.kernel.org/process/security-bugs.html
    As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
  • Reporter sempat punya waktu untuk memeriksa dan menyebut distro tertentu seperti Ubuntu/RHEL/SUSE di situsnya sendiri
    Paling tidak, memberi tahu tim keamanan distro-distro itu tampak seperti tindakan yang bertanggung jawab
  • Sulit menganggap masuk akal bahwa reporter membuat situs yang secara eksplisit menyebut Ubuntu, RedHat, Amazon, dan SUSE tetapi tidak memberi tahu mereka
    Tampaknya mustahil mereka tidak tahu bahwa distro-distro itu adalah downstream dari tim kernel
  • Mungkin itu bukan syarat mutlak, tetapi menurut saya semua orang jadi lebih menderita karena para reporter lebih tertarik pada ketenaran daripada remediasi yang aman
  • Sangat mudah mencari cara melaporkan isu keamanan seperti ini ke distro Linux
    Cukup cari di Google: https://share.google/aimode/eihDKXZJy94Z5lC1p
    Sulit dipahami bagaimana hal ini tidak terpikirkan lalu semua orang justru dipaparkan ke exploit, dan saya tidak akan heran jika di beberapa yurisdiksi itu tergolong kejahatan berat

• Pertukaran paling menarik terkait disclosure ada di tautan ini
  https://www.openwall.com/lists/oss-security/2026/05/01/3
  Ini adalah jawaban greg k-h: “Kami tidak bisa memberi tahu siapa pun sebelumnya, karena kalau begitu kami harus memberi tahu semua orang untuk semuanya. Itu satu-satunya kebijakan yang disetujui oleh lembaga hukum/pemerintah agar kami bisa beroperasi”

  • Saya suka Linux, tetapi menurut saya ini kebijakan yang bodoh

• Kita seharusnya berhenti menyalahkan reporter dan menuntut agar proses kernel diperbaiki
  Linux kernel bukan lagi proyek main-main, dan ada pegawai penuh waktu yang dipekerjakan oleh berbagai perusahaan
  Mereka, bukan individu acak, yang seharusnya menangani pemberitahuan ke distro

  • Namun, jika dalam posting blog pengumuman yang pada dasarnya bersifat pemasaran itu mereka sampai menyebut distro tertentu sebagai terdampak, menurut saya memberi heads-up sebelum publikasi adalah tindakan yang pantas dan wajar diharapkan
    Jika mereka tidak memasukkan penyebutan seperti RHEL 14, mungkin mereka tidak akan dikritik separah ini
    Ini bukan situasi peneliti keamanan independen atau akademik, melainkan perusahaan keamanan dengan departemen komunikasi profesional yang menunjuk-nunjuk maintainer distro
  • Memang benar distro dan pengembang kernel harus berkomunikasi soal patch dengan severity tinggi dan bergerak cepat
    Tetapi karena reporter tidak menunggu itu terjadi, orang sungguhan mungkin dirugikan, dan tanggung jawab atas itu ada pada reporter
  • Melaporkan kerentanan dan merilis exploit kuat yang bisa langsung dipakai siapa saja adalah dua hal yang sama sekali berbeda
    Melepaskannya ke dunia tanpa lebih dulu memberi tahu distro-distro utama adalah tindakan yang tidak bertanggung jawab

• Untuk orang yang memakai kernel dengan AF_ALG yang ditautkan langsung ke kernel, bukan sebagai modul, ada workaround berbasis eBPF di sini: https://github.com/Dabbleam/CVE-2026-31431-mitigation
  Saat ini saya menjalankannya di production, ini memitigasi serangan, dan sejauh ini belum terlihat efek samping tak terduga

• Menurut saya nosuid dan mungkin nodev seharusnya menjadi filesystem mount option bawaan
  /dev sudah berupa devtmpfs khusus, dan /dev minimal dari initrd kalau diperlukan bisa didapat dengan me-mount initrd tmpfs rootfs secara eksplisit dengan dev dan suid
  Membiarkan binary SUID bisa “ada” di mana saja adalah risiko keamanan besar
  Saat me-mount media penyimpanan eksternal, bagaimana kita bisa memverifikasi bahwa binary SUID di block device itu tidak berbahaya?
  Selain itu, exploit ini tampaknya hanya bekerja jika pengguna yang menjalankan binary SUID juga bisa membaca binary tersebut
  Tidak ada alasan bagi pengguna non-root untuk memiliki izin baca atas binary SUID
  NixOS menangani ini dengan benar
  Direktori instalasi paket biasa, /nix/store, tidak memiliki SUID, dan karena paket tidak bocor keluar dari sana, mountpoint lain bisa aman memakai nosuid
  Satu-satunya pengecualian hanyalah direktori tujuan tunggal /run/wrappers.$hash, yang aman menyimpan wrapper SUID executable-only

  • Saya juga tidak suka suid, tetapi suid bukan persoalan mendasar di sini
    Bug yang dieksploitasi pada dasarnya memungkinkan page cache poisoning sewenang-wenang
    Pada titik itu permainan pada dasarnya sudah selesai, dan menargetkan program suid mungkin memang cara termudah untuk mendapatkan root shell, tetapi bukan satu-satunya cara
  • proof of concept exploit secara harfiah hanya dimaksudkan untuk menunjukkan satu vektor serangan
    Ada banyak cara lain
    Jika tujuannya hanya memblokir exploit bukti konsep, metode yang lebih mudah seperti blacklist juga bisa dipakai, tetapi itu tidak membuat keadaan lebih aman
    Kerentanan ini memungkinkan manipulasi terhadap page cache
    Anda bisa memanipulasi ld.so untuk memasang hook pada system call arbitrer, mengubah uid menjadi 0, atau menaikkan hak akses dengan berbagai cara lain
    Mount point tidak ada hubungannya dengan masalah ini
    Tentu saja, mencegah suid di area yang bisa ditulis pengguna dan mencegah pembacaan file suid selalu ide bagus, tetapi itu karena alasan lain
    NixOS juga tidak bisa memperbaiki kerentanan ini dan tetap rentan seperti distro lainnya
  • Tanpa izin baca, Anda tidak bisa mengeksekusi binary, dan itu tidak masuk akal
    Untuk mengeksekusi binary, isinya harus dibaca dari disk dan dimuat ke memori
    Bahkan, jika suatu binary tertentu punya izin baca tetapi tidak punya izin executable, Anda masih bisa menjalankannya dengan memanggil linker secara langsung
    Misalnya, jika Anda memanggil /bin/ld.so.1 /path/to/binary, linker akan membaca dan memuat binary lalu melompat ke entry point tanpa memanggil exec()

• Tautan Bleeping Computer di bawah memuat langkah-langkah mitigasi potensial sampai patch siap
  https://www.bleepingcomputer.com/news/security/new-linux-cop...

  • Workaround ini hanya berlaku untuk kernel yang mengompilasi kode terdampak sebagai modul
    RHEL, Fedora, dan Gentoo semuanya dikonfigurasi untuk membangun kode ini langsung ke dalam kernel
    Tanpa patch atau perubahan konfigurasi, seperti yang diisyaratkan Sam soal Gentoo, distro-distro itu akan tetap rentan
  • Pada RedHat dan distro turunannya, kode terdampak dikompilasi secara statis, bukan sebagai modul, jadi mitigasi ini tidak bekerja

• NixOS juga tidak menerima pemberitahuan
  https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

  • Tidak ada distro mana pun yang menerima pemberitahuan

• Hyperbola GNU aman karena alasan politik dan stabilitas masih memakai Python 3.8

• Ubuntu sudah merilis patch, dan pengujian juga telah selesai sebelum dan sesudah patch