Looney Tunables CVE-2023-4911, Celah glibc di Linux

Apakah server Linux-mu masih rentan terhadap Looney Tunables? Kalau paket glibc sudah diperbarui sejak Oktober 2023, jawabannya hampir pasti tidak. Tapi server yang lama tidak disentuh, image Docker lawas, atau VPS yang update otomatisnya mati, masih layak dicek.

Looney Tunables adalah nama yang diberikan tim riset Qualys untuk CVE-2023-4911, celah di GNU C Library (glibc). Celah ini membuat pengguna lokal tanpa hak istimewa bisa menjadi root. Karena glibc dipakai hampir semua program di Linux, jangkauannya sangat luas.

Apa yang terjadi di glibc?

Glibc punya fitur "tunables", yaitu pengaturan perilaku pustaka lewat variabel lingkungan GLIBC_TUNABLES. Dynamic loader ld.so, komponen yang memuat pustaka setiap kali program dijalankan, salah memproses isi variabel ini sehingga terjadi buffer overflow.

Masalah menjadi serius saat yang dijalankan adalah program SUID, yaitu program yang otomatis berjalan dengan hak pemiliknya (biasanya root). Pengguna biasa yang menjalankan program SUID dengan variabel lingkungan hasil rekayasa bisa membuat kode miliknya ikut berjalan sebagai root.

Skor CVSS 3.1-nya 7.8 (High). Angkanya tidak setinggi celah jarak jauh karena penyerang harus sudah punya akses lokal, misalnya akun shell biasa atau proses aplikasi web yang sudah dibobol. Namun di dunia nyata, celah seperti ini sering menjadi langkah kedua setelah penyerang masuk lewat celah lain.

Menurut Qualys, kodenya masuk ke glibc pada April 2021 dan dirilis di glibc 2.34. Qualys mengumumkannya pada 3 Oktober 2023 dan berhasil memperoleh root pada instalasi bawaan Fedora 37 dan 38, Ubuntu 22.04 dan 23.04, serta Debian 12 dan 13. Alpine Linux tidak terdampak karena memakai musl, bukan glibc.

CISA memasukkan CVE-2023-4911 ke katalog Known Exploited Vulnerabilities pada 21 November 2023, artinya celah ini sudah terbukti dipakai dalam serangan nyata.

Cara mengecek dan menambal server

Langkah 1: Kenali distro dan versinya

Jalankan cat /etc/os-release. Hasilnya menentukan perintah berikutnya. Sebagai patokan dari halaman keamanan resmi masing-masing distro:

• Ubuntu: 22.04 dan 23.04 tercatat terdampak sebelum ditambal. 20.04 dan 18.04 tercatat tidak terdampak, sedangkan 24.04 sudah membawa paket yang diperbaiki.
• Debian: 12 (bookworm) terdampak. Debian 11 (bullseye) juga mendapat perbaikan karena kode rentannya sempat di-backport ke paketnya. Debian 10 (buster) tidak terdampak.
• RHEL dan turunannya: Red Hat menyebut kode rentan di-backport ke RHEL 8.5, sehingga RHEL 8.5 ke atas ikut terdampak. Keluarga RHEL 9 memakai glibc 2.34 sehingga juga perlu dicek.

Langkah 2: Cek versi paket glibc

Di Ubuntu dan Debian:

dpkg -l libc6 | grep ^ii

Di AlmaLinux, Rocky Linux, atau RHEL:

rpm -q glibc

Bandingkan hasilnya dengan versi perbaikan. Untuk Ubuntu, halaman keamanan Canonical mencantumkan 2.35-0ubuntu3.4 untuk 22.04 dan 2.37-0ubuntu2.1 untuk 23.04. Versi yang lebih baru dari angka itu sudah membawa perbaikan. Untuk Debian, perbaikannya dirilis lewat DSA-5514-1, dan Debian Security Tracker mencantumkan versi paket terbaru per rilis.

Langkah 3: Perbarui glibc

Di Ubuntu dan Debian:

sudo apt update
sudo apt install --only-upgrade libc6

Di keluarga RHEL:

sudo dnf update glibc

Lebih baik lagi, jalankan update sistem penuh sekalian agar celah lain ikut tertutup.

Langkah 4: Reboot atau restart layanan

Program yang sudah berjalan masih memegang salinan glibc lama di memori. Cara paling bersih adalah reboot setelah update glibc. Bila reboot harus dijadwalkan, alat seperti needrestart di Ubuntu atau needs-restarting -r dari paket dnf-utils membantu melihat apa saja yang perlu dimulai ulang.

Langkah 5: Pastikan update berikutnya otomatis

Celah seperti ini biasanya diumumkan bersamaan dengan paket perbaikan. Server yang update keamanannya otomatis sudah aman dalam hitungan hari. Panduan update keamanan otomatis di Ubuntu menjelaskan cara menyalakannya.

Bagaimana dengan container dan image Docker?

Container memakai glibc dari image-nya sendiri, bukan dari host. Image berbasis Debian 12 atau Ubuntu 22.04 yang dibangun sebelum perbaikan masih membawa glibc rentan sampai dibangun ulang. Risikonya lebih kecil bila container tidak berisi program SUID dan tidak berjalan sebagai root, tapi tetap sebaiknya dibangun ulang dari image dasar terbaru. Pemindai seperti Trivy bisa menemukan paket glibc lama di image, seperti dibahas di cara scan image Docker dengan Trivy.

Ringkasan per distro

Checklist singkat sebelum menutup tiket:

• Versi paket glibc sudah sama atau lebih baru dari versi perbaikan distro.
• Server sudah reboot atau layanan penting sudah dimulai ulang.
• Image container dibangun ulang dari image dasar terbaru.
• Update keamanan otomatis aktif untuk ke depannya.