Copy Fail: Exploit 4 byte, User biasa jadi Root di Linux

Apa itu Copy Fail?

Copy Fail adalah bug logika di Linux kernel. Dari laporan yang ada, masalahnya muncul dari interaksi template kripto authencesn, interface socket AF_ALG, dan system call splice(). Namanya Copy Fail karena inti bug-nya ada di asumsi soal copy data versus referensi langsung ke page cache. Versi warung kopinya: sistem kira lagi pegang fotokopian, ternyata yang dipegang barang asli.

Cyber Security News menyebut bug ini ditemukan oleh Taeyang Lee dari Theori, lalu dikembangkan menjadi exploit chain penuh oleh Xint Code Research Team dengan bantuan analisis AI. Detail ini bukan buat bikin AI kelihatan sakti. Poinnya lebih sederhana: riset security makin sering jadi kerja bareng antara manusia dan tooling analisis. Keren? Iya. Bikin merinding sedikit? Juga iya.

Catatan penting: ini local privilege escalation. Attacker butuh akses lokal dulu. Tapi jangan langsung santai. Banyak serangan besar mulai dari akses kecil: web shell, service account bocor, credential reuse, dependency rentan, atau akun internal yang kebanyakan izin. Begitu ada pijakan, bug lokal seperti ini bisa jadi tangga ke root. Tangga yang licin buat defender, nyaman buat attacker.

Fakta teknis dari laporan sumber

Dari laporan Cyber Security News, Copy Fail punya beberapa ciri yang membuatnya beda dari banyak bug kernel lain.

Cara kerja tingkat tinggi

Bagian ini sengaja tetap di level tinggi. Tujuannya memahami risiko, bukan memberi resep exploit.

Linux memakai page cache untuk menyimpan representasi file di memori. Normalnya, kalau data file berubah, kernel menandai halaman itu sebagai dirty supaya perubahan bisa ditulis balik ke disk. Pada Copy Fail, laporan sumber menyebut exploit bisa memicu controlled 4-byte write ke page cache milik file yang bisa dibaca attacker. Jadi 4 byte di sini bukan ukuran exploit, tapi ukuran coretan kecil yang bisa ditulis ke page cache secara terkontrol.

Masalahnya ada di sini: kernel tidak menandai halaman yang korup itu sebagai dirty untuk writeback. File di disk tetap tidak berubah. Jadi tool integritas yang cuma menghitung checksum file di disk bisa tetap bilang bersih. Di permukaan aman. Di memori, versi file yang dieksekusi sudah beda. Ini tipe bug yang bikin orang security menatap dashboard sambil ngomong pelan, “lah, kok bisa?”

Laporan juga menyebut attacker mengeksekusi versi in-memory dari binary setuid seperti /usr/bin/su untuk mendapatkan root shell. Ini konteks dampak, bukan instruksi. Buat defender, pelajarannya jelas: jangan cuma mengandalkan file integrity monitoring berbasis disk. Ada serangan yang main di memori dan page cache, bukan nulis malware terang-terangan ke filesystem.

Kenapa 732 byte dan 4 byte bisa bikin ribet?

Biar nggak ketuker: 732 byte itu ukuran script exploit yang disebut di laporan. Sedangkan 4 byte itu ukuran write primitive, yaitu coretan kecil yang bisa diarahkan ke page cache. Dua angka ini ngomongin hal yang beda.

Di level aplikasi, 732 byte terasa kecil. Bahkan lebih kecil dari chat “otw” yang ternyata dikirim pas orangnya masih mandi. Tapi dalam konteks exploit kernel, ukuran file kecil tidak berarti dampaknya kecil. Kalau bug logikanya pas, script mungil tetap bisa memanfaatkan jalur sistem yang sensitif.

Lalu 4 byte-nya apa? Itu bukan ukuran file exploit. Itu ukuran data yang ditulis tiap primitive ke page cache. Kecil banget, tapi kalau offset-nya tepat, 4 byte bisa cukup untuk mengubah instruksi, flag, atau bagian sensitif lain dari data yang sedang dipakai kernel di memori.

Copy Fail menarik karena laporan menyebut exploit-nya hanya 732 byte dan memakai modul standard library Python, tapi efek teknisnya datang dari controlled 4-byte write ke page cache. Ini bukan berarti semua orang mendadak bisa jadi researcher kernel. Risetnya tetap dalam. Tapi setelah exploit tersedia, hambatan operasional untuk penyalahgunaan bisa turun. Yang perlu ditakuti tim infra bukan cuma siapa yang bisa menemukan bug, tapi siapa yang bisa menjalankan hasil akhirnya.

Kenapa file integrity tool bisa kelewat?

Banyak organisasi memakai checksum untuk memastikan file penting tidak berubah. Cara ini tetap berguna, tapi Copy Fail menunjukkan batasnya.

Kalau file di disk tidak berubah, checksum file di disk juga tidak berubah. Kalau korupsi terjadi di page cache dan tidak ditandai dirty, alat yang cuma melihat disk bisa bilang “aman” sementara eksekusi di memori sudah berbeda. Rasanya seperti ngecek KTP di meja resepsionis, padahal orangnya masuk lewat pintu belakang pakai jaket orang lain.

Dampaknya jelas: monitoring perlu lebih dari hash file. Defender perlu melihat perilaku proses, perubahan privilege, pemanggilan binary sensitif, aktivitas service account, dan pola eksekusi yang tidak biasa. File integrity monitoring bagus. Tapi kalau dia jadi satu-satunya penjaga malam, ya jangan kaget kalau maling lewat samping.

Dampak ke server produksi

Server produksi sering rentan bukan karena satu kesalahan besar, tapi karena tumpukan hal kecil yang dibiarkan. Kernel agak lama. Patch window mundur. VM lama tidak masuk inventaris. CI runner dianggap sementara. Node Kubernetes lupa direboot setelah update. Lalu ada user lokal yang awalnya terlihat biasa saja, sampai ada bug privilege escalation.

Untuk Copy Fail, risiko utama ada pada sistem tempat attacker bisa mendapat akses lokal. Jalannya bisa macam-macam:

• aplikasi web yang sudah dikompromi;
• akun developer atau service account bocor;
• container escape path yang dibantu konfigurasi lemah;
• shell terbatas yang ternyata cukup untuk menjalankan proses lokal;
• workload multi-tenant dengan isolasi kurang ketat;
• server lama yang tidak masuk patch management.

Kalau salah satu jalur itu terbuka, local privilege escalation bisa mengubah insiden kecil menjadi insiden root. Begitu root didapat, biasanya cerita tidak makin lucu. Biasanya mulai ada yang minta timeline insiden.

Dampak ke container dan Kubernetes

Container bukan jimat. Perlu diulang karena masih banyak yang memperlakukan Docker seperti pagar gaib.

Container berbagi kernel dengan host. Kalau bug-nya ada di kernel, container bisa ikut terdampak, tergantung konfigurasi. Risiko makin besar kalau container berjalan dengan izin terlalu luas: privileged mode, capability berlebihan, mount host yang longgar, seccomp profile lemah, atau AppArmor/SELinux tidak aktif.

Untuk Kubernetes, cek node kernel version, runtime configuration, Pod Security Admission, capability, hostPath mount, dan workload yang berjalan sebagai root. Kalau cluster punya banyak tenant, risikonya naik. Kalau CI runner berjalan di container dengan akses terlalu royal, risikonya juga naik. CI runner sering jadi tempat dosa kecil berkumpul: token, akses repo, cache, artifact, dan script dari macam-macam sumber. Jangan tambah dosa baru dengan memberi jalan gampang ke host.

Indikator yang perlu dipantau

Tidak ada satu indikator sakti untuk semua kasus. Untuk risiko privilege escalation lokal, defender bisa mulai dari pola ini:

• eksekusi binary setuid yang tidak biasa;
• proses user rendah yang tiba-tiba punya privilege tinggi;
• pemanggilan AF_ALG atau pola crypto socket yang tidak lazim di server itu;
• penggunaan splice() dari proses yang biasanya tidak menyentuh operasi file level rendah;
• shell interaktif yang muncul dari service account;
• proses pendek yang muncul, naik privilege, lalu hilang;
• anomali audit log terkait eksekusi /usr/bin/su, sudo, atau binary setuid lain;
• aktivitas aneh dari container yang seharusnya cuma menjalankan satu aplikasi.

Jangan pakai daftar ini sebagai checklist mati. Pakai sebagai titik awal. Tiap environment punya baseline sendiri. Server database, node Kubernetes, CI runner, dan bastion host punya perilaku normal yang beda. Kalau semua dipukul rata, hasilnya noise. Kalau tidak dipantau sama sekali, hasilnya doa.

Langkah mitigasi

Checklist defensif

Pakai checklist ini untuk koordinasi cepat antar tim.

1
- [ ] Daftar semua host Linux dan versi kernel aktif.
2
- [ ] Cocokkan versi kernel dengan advisory vendor.
3
- [ ] Patch host rentan sesuai prioritas risiko.
4
- [ ] Reboot host yang butuh kernel baru.
5
- [ ] Validasi kernel aktif setelah reboot.
6
- [ ] Review container privileged dan capability berlebihan.
7
- [ ] Review binary setuid penting.
8
- [ ] Pantau eksekusi `/usr/bin/su`, `sudo`, dan perubahan UID aneh.
9
- [ ] Tambahkan deteksi perilaku untuk proses lokal mencurigakan.
10
- [ ] Dokumentasikan host yang belum bisa dipatch beserta alasan dan jadwal.

Catatan untuk tim security

Copy Fail mengingatkan satu hal: audit di atas kertas tidak selalu melihat bug yang hidup di bawah lantai. Compliance tetap perlu, tapi jangan disamakan dengan security nyata. Kalau sistem lolos checklist tapi kernel tertinggal, service account terlalu sakti, dan container berjalan privileged, itu bukan aman. Itu cuma rapi di spreadsheet.

Tim security perlu bicara dengan bahasa operasional. Jangan cuma bilang “segera patch.” Kasih prioritas, dampak, daftar host, owner, deadline, dan cara validasi. Tim infra juga jangan menunggu semua detail sempurna baru bergerak. Untuk bug kernel dengan potensi root, respons cepat sering lebih berguna daripada rapat panjang yang ujungnya cuma menghasilkan notulen cantik.

Catatan untuk tim infra

Patching kernel memang tidak selalu gampang. Ada uptime, dependency, maintenance window, aplikasi legacy, dan stakeholder yang baru peduli server ketika server mati. Tapi menunda patch tanpa mitigasi juga bukan strategi. Itu cuma berharap attacker sedang cuti.

Bikin jalur kerja yang jelas:

1. identifikasi host rentan;
2. kelompokkan berdasarkan risiko;
3. patch dan reboot kelompok risiko tinggi dulu;
4. validasi kernel aktif;
5. catat pengecualian;
6. pasang monitoring ekstra sampai semua host selesai.

Kalau patch harus ditunda karena alasan bisnis, tulis risikonya secara eksplisit. Jangan biarkan keputusan besar hidup sebagai “nanti dulu ya” di chat.

Kesalahan mindset yang sering muncul

Kesimpulan

Copy Fail bukan cuma cerita soal exploit 732 byte atau write primitive 4 byte. Ini cerita soal asumsi yang terlalu nyaman. Kernel dianggap aman. Container dianggap cukup. Checksum dianggap pasti melihat perubahan. Server internal dianggap tidak menarik. Lalu satu bug datang dan semua asumsi itu kena tampar.

Respons terbaik bukan panik. Respons terbaik itu rapi dan cepat: inventaris kernel, patch vendor, reboot, validasi, kurangi privilege, pantau perilaku, dan dokumentasikan pengecualian. Kalau ada host yang belum bisa dipatch, perlakukan sebagai risiko aktif, bukan catatan kaki.

Pada akhirnya, yang bahaya bukan cuma hacker hebat. Yang lebih sering bikin repot adalah sistem yang terlalu dipercaya, terlalu jarang dicek, dan terlalu lama dibiarkan karena “selama ini aman.” Kalimat itu enak didengar sampai hari ketika script sekecil 732 byte mengetuk pintu dan bertanya, “root-nya di mana, bang?”

Referensi

• Cyber Security News: https://cybersecuritynews.com/linux-kernel-0-day-copy-fail/