CVE-2026-31431 (Copy Fail) - Cara Kami Memitigasinya

Minggu lalu sebuah local privilege escalation serius pada kernel Linux diungkap: CVE-2026-31431, dijuluki "Copy Fail". Celah ini memengaruhi berbagai versi kernel di distribusi Linux modern, dan exploit publik muncul cepat setelah pengungkapan.

Saya ingin menjelaskan secara terbuka apa yang terjadi, apa artinya untuk Appbox, dan apa yang sudah kami lakukan. Versi singkatnya: berkat cara container kami dibangun, aplikasi yang berjalan dengan user namespace remapping sudah terlindungi agar ini tidak berubah menjadi host root bahkan sebelum kernel yang dipatch diluncurkan. Kemarin (4 Mei 2026), kami juga melakukan maintenance darurat untuk meng-upgrade setiap server ke kernel yang sudah dipatch, sehingga bug tersebut sekarang sudah sepenuhnya hilang dari fleet kami.

Apa itu "Copy Fail"?

CVE-2026-31431 adalah celah pada API kriptografi AF_ALG kernel. Dengan melakukan bind ke cipher tertentu (authencesn(hmac(sha256),cbc(aes))) dan menyalahgunakan cara kernel menyambung page ke scratch buffer, pengguna lokal tanpa privilege dapat menulis chunk arbitrer 4-byte langsung ke page cache file yang seharusnya tidak boleh mereka ubah - termasuk binary SUID seperti /usr/bin/su.

Setelah salinan page cache dari su ditimpa dengan ELF malicious kecil, pemanggilan berikutnya menjalankan kode penyerang sebagai UID 0. Selesai sudah untuk host.

Untuk detail teknis yang mendalam (disassembly shellcode, trace syscall, semuanya), tulisan Andrea Veri sangat bagus: CVE-2026-31431: Copy Fail vs. rootless containers. Ia juga mendemonstrasikan - dengan eBPF dan bukti uid_map - tepat yang akan kita bahas berikutnya: user namespace menetralkan exploit ini.

Mengapa Aplikasi Appbox Sudah Termitigasi

Exploit ini bergantung pada setuid(0) yang benar-benar memberikan host root. Dalam container yang berjalan dengan user namespaces aktif, bukan itu yang terjadi.

User namespace memetakan ruang UID container ke rentang UID berbeda (tanpa privilege) di host. Jadi ketika exploit berhasil di dalam container dan setuid(0) mengembalikan sukses, shell "root" yang dihasilkan dipetakan ke pengguna host biasa tanpa privilege - bukan root sungguhan. Shellcode berjalan, prompt berubah menjadi #, tetapi di host:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

Itu saja. Tidak ada akses file host, tidak ada /etc/shadow, tidak ada host root. Batas namespace container mencegah ini menjadi host-root escape.

Di level platform, setiap Appbox mendapatkan Docker daemon sendiri yang dimulai dengan user namespace remapping aktif. Dalam pseudocode, bentuknya kira-kira seperti ini:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Mapping itu didukung oleh rentang UID/GID subordinate khusus di host:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

Di atas itu, definisi aplikasi masih dapat secara eksplisit menimpa UsernsMode saat aplikasi membutuhkan penanganan khusus:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

Jadi cara akurat untuk mendeskripsikannya adalah: user namespace remapping adalah bagian dari default platform, dan pengecualian per aplikasi bersifat eksplisit. Ada sejumlah kecil aplikasi yang membutuhkan pengaturan berbeda karena mengekspos fungsi yang memerlukan capability tambahan, dan kasus tersebut ditangani terpisah.

Dengan kata lain: untuk aplikasi yang berjalan dengan setup remapping normal, Copy Fail tidak dapat mengubah kompromi container menjadi host root.

Apa yang Tetap Ingin Kami Perbaiki

User namespace menghentikan host escape, tetapi tidak membuat bug tersebut hilang di dalam container. Penyerang masih bisa naik menjadi "container root" dalam batas aplikasi, yang meski terkurung, tetap bukan hal baik. Kernel itu sendiri rentan, dan kami ingin itu hilang.

Begitu mengetahui bug ini, kami langsung mulai menilai eksposur kami. Meskipun user namespace remapping sudah memblokir sisi host-escape dari masalah ini untuk setup aplikasi normal kami, kami tetap ingin bug kernel dasarnya hilang secepat mungkin.

Apa yang Kami Lakukan Kemarin

Pada Minggu malam kami menjadwalkan maintenance darurat untuk Senin, 4 Mei 2026, jendela paling awal untuk meluncurkan upgrade kernel ke seluruh fleet.

Selama jendela tersebut:

• Setiap host di-upgrade menggunakan package kernel Debian resmi yang berisi perbaikan "Copy Fail".
• Tujuannya sederhana: menghapus path kernel yang rentan sepenuhnya, bukan hanya mengandalkan isolasi namespace yang sudah ada.

Maintenance selesai. Setiap host Appbox sekarang menjalankan kernel yang sudah dipatch.

Apa Artinya untuk Anda

• Anda tidak perlu melakukan apa pun. Aplikasi Anda tetap berjalan dan gangguan singkat apa pun selama jendela maintenance adalah satu-satunya efek yang terlihat oleh pelanggan.
• Bahkan sebelum patch kemarin, user namespace remapping berarti bug ini tidak dapat mengubah kompromi aplikasi normal menjadi host root. Itulah tepatnya skenario yang ingin dicegah oleh model isolasi ini.
• Ke depan, kebijakan kami tidak berubah: user namespace tetap aktif secara default, dan sedikit pengecualian melewati review keamanan tambahan.

Gambaran Besarnya

Ini salah satu CVE yang headline-nya ("local privilege escalation, exploit publik, setiap kernel modern terdampak") terdengar katastrofik, dan untuk banyak environment shared-tenant memang begitu. Alasan ini tidak katastrofik bagi kami sama dengan alasan kami mengambil keputusan arsitektur bertahun-tahun lalu yang kadang mengorbankan sedikit kompatibilitas: kami menjalankan aplikasi dengan prinsip least privilege yang tertanam di layer container, bukan ditempelkan belakangan.

Defence in depth benar-benar bekerja. Bug di layer kernel? Layer namespace menangkapnya. Bug di layer namespace? Capability drop dan seccomp menangkap sebagian besar sisanya. Kami tidak berpura-pura satu layer sempurna, kami hanya memastikan selalu ada layer berikutnya.

Jika Anda punya pertanyaan tentang ini, atau tentang bagaimana aplikasi spesifik Anda dikonfigurasi, silakan hubungi kami.

Ada pertanyaan? Hubungi kami di support@appbox.co atau buka tiket di billing.appbox.co.