Belajar Seccomp - CVE Awareness & Security Patches

#Pendahuluan

Di episode 13 kalian menyusun deny-list untuk syscall berbahaya dan memverifikasinya bekerja. Filter terpasang, syscall yang diblokir benar-benar ditolak — rasanya aman. Tetapi ada satu pertanyaan yang jarang diajukan: dari bahan apa filter itu disusun, dan seberapa bisa dipercaya bahan itu?

Sebuah filter seccomp jarang ditulis sebagai bytecode BPF manual. Hampir semua profile yang kalian pakai — profile default Docker, aturan SystemCallFilter di systemd, filter di runc dan Kubernetes — disusun oleh libseccomp, library C yang menerjemahkan aturan deklaratif menjadi program BPF. Setiap kali kalian menulis aturan di file JSON, di dalamnya libseccomp lah yang bekerja. Ini analog dengan kontraktor yang menyusun bata menjadi dinding: dinding tampak kokoh dari luar, tetapi jika kontraktornya ceroboh, ada lubang yang tidak terlihat.

Pada Juli 2026, tiga advisory keamanan untuk libseccomp 2.6.1 dirilis sekaligus — dan ketiganya menegaskan satu pelajaran: filter yang tampak kuat bisa lemah. Episode ini membedah tiga CVE tersebut, dampaknya terhadap filter kalian, dan praktik terbaik untuk menjaga library penyusun filter selalu sehat. Mari mulai.

#Pembahasan Utama

#Mengapa libseccomp Begitu Penting

libseccomp adalah lapisan yang hampir tidak terlihat tetapi dipakai di mana-mana: Docker dan containerd menyusun profile default lewat binding seccomp-golang, systemd menerjemahkan SystemCallFilter= menjadi BPF melaluinya, dan hampir semua aplikasi yang memasang filter — dari Chromium hingga server aplikasi — memakainya. Menulis filter "manual" di level BPF murni sangat jarang dan rawan kesalahan.

Konsekuensinya tegas: kualitas filter kalian tidak pernah lebih baik dari kualitas libseccomp di sistem. Jika library-nya memiliki bug dalam menerjemahkan aturan, filter yang dihasilkan bisa salah — dan yang paling berbahaya adalah salah ke arah "mengizinkan". Inilah inti masalah CVE yang akan kita bahas.

#CVE libseccomp 2.6.1: Tiga Advisory Juli 2026

Tiga advisory dirilis untuk jalur 2.6.1 pada Juli 2026. Dua di antaranya menyangkut filter berukuran besar, dan satu menyangkut penggabungan perbandingan 64-bit — yang terakhir ini yang paling mengancam postur keamanan kalian.

Advisory	Masalah	Dampak pada filter kalian
GHSA-4q85-33p6-j5g6	Kesalahan penggabungan perbandingan argumen 64-bit	Filter hasil gabungan bisa lebih lemah: perbandingan argumen yang seharusnya membatasi bisa terlewat
GHSA-46fr-jh49-xvhx	Double free pada filter berukuran besar	Proses penyusun filter bisa crash atau korup memori saat mengompilasi filter kompleks
GHSA-2hqh-5c36-grrm	Heap corruption pada filter berukuran besar	Korupsi heap yang bisa dimanfaatkan untuk menyabotase proses yang menyusun filter

#GHSA-4q85-33p6-j5g6: Perbandingan 64-bit yang Melemah Saat Digabung

Advisory pertama adalah yang paling serius. libseccomp mengoptimasi filter dengan menggabungkan aturan-aturan yang saling berdekatan — misalnya dua aturan untuk syscall yang sama dengan argumen berbeda, atau percabangan yang hasilnya bisa disederhanakan. Dalam proses merge inilah bug muncul: pada kasus tertentu, perbandingan terhadap argumen 64-bit (dibahas di episode 5 tentang argfilter, dan akan kita perjelas lagi di episode 17 dengan SCMP_CMP64) digabung secara keliru sehingga batasannya hilang.

Apa artinya bagi kalian? Kalian menulis aturan "syscall ini hanya diizinkan jika argumen sama dengan nilai X". Filter yang dihasilkan terlihat benar saat di-review. Namun karena bug di merge, dalam kondisi tertentu nilai X tidak pernah benar-benar diperiksa — syscall tersebut diizinkan untuk semua argumen. Filter yang tampak kuat menjadi lemah, dan tidak ada yang tahu sampai sebuah serangan memanfaatkannya.

Warning

Inilah pelajaran paling berharga dari episode ini: aturan yang terlihat di config tidak menjamin aturan yang terpasang di kernel. Setiap kali library penyusun filter di-update, kalian harus menguji ulang bahwa aturan argumen benar-benar menegakkan pembatasan — jangan hanya mengandalkan hasil review teks.

#GHSA-46fr-jh49-xvhx dan GHSA-2hqh-5c36-grrm: Bahaya Filter Oversized

Dua advisory berikutnya muncul dari jalur yang sama: filter yang terlalu besar. Saat libseccomp mengompilasi filter dengan ribuan aturan, buffer internalnya meluap dengan cara yang tidak aman — satu kasus menghasilkan double free, kasus lain heap corruption.

Dampak langsungnya berbeda dari advisory pertama. Ini bukan soal filter yang lemah, melainkan proses yang menyusun filter bisa crash atau memori-nya dikorupsi. Bagi penyerang yang sudah bisa memengaruhi proses penyusun filter — misalnya lewat input yang diterjemahkan menjadi aturan filter — ini bisa menjadi primitive serangan tersendiri.

Hikmahnya sederhana dan mengarah ke praktik yang sudah lama dianjurkan: jangan membuat filter raksasa. Filter yang besar tidak hanya lebih lambat dievaluasi (episode 18), tetapi juga menembus jalur kode yang paling jarang diuji — dan di situlah bug-bug ini bersembunyi.

#Implikasi: Filter yang Tampak Kuat Bisa Lemah

Rangkai ketiganya dan kalian mendapat satu gambaran utuh: filter kalian bisa lemah tanpa pernah terlihat. Perbandingan argumen bisa hilang diam-diam saat digabung, filter besar bisa memicu bug memory safety di penyusunnya, dan semua itu terjadi di balik layar — file config tetap terlihat benar, profile tetap terlihat lengkap.

Inilah mengapa CVE awareness bukan sekadar mengikuti berita keamanan. Ia adalah disiplin operasional: mengetahui komponen apa saja yang menyusun pertahanan kalian, melacak version-nya, dan memperlakukan update library sebagai bagian dari siklus hardening — bukan acara insidental.

#Best Practice 1: Update Rutin

Langkah pertama yang tidak bisa ditawar: selalu pakai libseccomp terbaru di setiap host dan di setiap pipeline build image. Kerentanan ditambal oleh vendor lebih cepat daripada kalian menemukannya sendiri.

Cek versi libseccomp yang terpasang

dpkg -l libseccomp2   # Debian/Ubuntu
rpm -q libseccomp     # RHEL/Rocky

sudo apt update
sudo apt upgrade -y libseccomp2 libseccomp-dev

Perhatikan bahwa update harus terjadi di dua tempat: host yang menjalankan runtime container (Docker/runc memakai libseccomp host lewat binding), dan image yang kalian bangun. Filter di-compile saat proses berjalan — jadi meng-update library tidak cukup tanpa me-restart workload yang memakainya.

Catatan penting: mematikan profile seccomp sementara — misalnya dengan --security-opt seccomp=unconfined di Docker — juga berarti melewati jalur libseccomp yang sedang bermasalah, tetapi membuang seluruh lapisan filter. Gunakan hanya untuk debugging sesaat, bukan sebagai solusi.

Rebuild image setelah update library

docker build --no-cache -t app:latest .
sudo systemctl restart docker

Filter dikompilasi saat runtime dari library host — restart juga wajib

Tip

Jadikan update libseccomp bagian dari jadwal rutin — misalnya ikut dalam siklus patching bulanan. Untuk tim yang lebih matang, jadwalkan job yang mengecek versi libseccomp di semua host dan melaporkan yang tertinggal, persis pola otomatisasi yang dibahas di episode-episode CI/CD series ini.

#Best Practice 2: Review Filter dan Jangan Membuatnya Oversized

CVE di atas lahir dari dua hal: penggabungan aturan dan ukuran filter. Keduanya bisa dikendalikan dari sisi desain:

Pecah filter besar menjadi beberapa filter kecil. Kernel mendukung pemasangan banyak filter secara aditif (kita bahas mekanismenya di episode 16). Satu filter besar yang berisi segalanya lebih sulit di-review dan menembus jalur kode berisiko.
Utamakan allow-list yang kecil. Allow-list default-deny dengan beberapa puluh syscall jauh lebih aman dan lebih mudah diverifikasi daripada deny-list raksasa berisi ratusan aturan.
Hindari aturan argumen yang berlebihan. Setiap SCMP_CMP64 menambah kompleksitas merge — dan kompleksitas merge adalah lokasi bug advisory pertama. Gunakan perbandingan hanya di tempat yang benar-benar bernilai.
Review berkala. Tanyakan setiap aturan: apakah masih dibutuhkan workload? Apakah bisa disederhanakan? Filter yang tidak pernah di-review adalah dokumentasi yang membusuk — dan kali ini, pembusukannya bisa menjadi celah keamanan.

#Checklist Menjaga Kesehatan Filter

Praktik	Kapan	Tujuan
Update libseccomp host	Rutin (bulanan)	Menutup CVE di library penyusun
Rebuild dan restart workload	Setelah update	Menerapkan filter hasil library baru
Uji ulang aturan argumen	Setiap update library	Mendeteksi perbandingan yang melemah
Review profile	Per rilis aplikasi	Membuang aturan yang tidak dipakai
Hindari filter oversized	Saat mendesain	Menghindari jalur kode berisiko dan biaya evaluasi

#Penutup

Pada episode 14 ini kalian memahami bahwa kekuatan filter seccomp ditentukan oleh library yang menyusunnya. Tiga advisory libseccomp 2.6.1 yang dirilis Juli 2026 mengajarkan pelajaran yang sama dari sudut berbeda: perbandingan 64-bit yang melemah saat digabung, double free dan heap corruption pada filter besar. Filter yang tampak kuat bisa lemah — dan satu-satunya pertahanan adalah disiplin update, review, dan desain filter yang tidak berlebihan.

Poin kunci yang perlu kalian bawa:

libseccomp menyusun hampir semua filter di ekosistem — kualitas filter tidak pernah melebihi kualitas library-nya.
GHSA-4q85-33p6-j5g6 bisa menghilangkan batasan argumen secara diam-diam saat aturan digabung.
Filter oversized memicu double free dan heap corruption di libseccomp.
Update rutin, rebuild image, review berkala, dan filter yang ramping adalah obatnya.

Semua pembahasan sejauh ini mengasumsikan kalian bisa melihat apa yang terjadi di dalam filter. Kenyataannya, seccomp sering menjadi kotak hitam: filter terpasang, denial terjadi, tetapi tidak ada yang tahu kapan dan mengapa. Di episode 15 berikutnya kita akan membuka kotak itu — audit & monitoring syscall: audit framework, SECCOMP_RET_LOG dan journald, deteksi percobaan yang diblokir, hingga telemetri denial rate dan profiling workload dengan strace -c dan bpftrace. Sampai jumpa!