Dalam kertas putih baru, Kernel Vendor, Bug dan Stabilitasperangkat lunak infrastruktur dan Linux berbatu perusahaan CIQ menyajikan argumen yang meyakinkan bahwa kernel vendor Linux memiliki kerentanan keamanan karena proses rekayasa yang cacat yang melakukan perbaikan backport.
Juga: Tiga peningkatan kernel Linux 6.9 teratas
Meskipun hal ini mungkin mengejutkan sebagian orang, ini adalah rahasia umum di komunitas Linux. Seperti yang baru-baru ini dikatakan Greg Kroah-Hartman, pengelola kernel stabil Linux dan anggota terkemuka tim keamanan kernel: Agar aman, Anda harus selalu menggunakan kernel stabil jangka panjang terbaru. Kata kuncinya di sini adalah “terbaru”. Menggunakan LTS saja tidak cukup. Anda harus menggunakan rilis terbaru agar seaman mungkin.
Sayangnya, hampir tidak ada orang yang melakukan hal tersebut. Namun demikian, seperti yang dijelaskan oleh insinyur kernel Google Linux Kees Cook, “Jadi, apa yang harus dilakukan vendor? Jawabannya sederhana: jika menyakitkan: Terus perbarui ke rilis kernel terbarubaik mayor atau stabil.”
Mengapa? Seperti yang dijelaskan Kroah-Hartman, “Setiap bug berpotensi menjadi masalah keamanan di tingkat kernel.”
Jonathan Corbet, pengembang kernel Linux dan pemimpin redaksi LWN, setuju: “Di dalam kernel, hampir semua bug, jika Anda cukup pintar, dapat dieksploitasi untuk menyusupi sistem. Kernel berada di tempat yang unik di dalam sistem. sistem…itu mengubah banyak bug biasa menjadi kerentanan.”
Apa yang dilakukan insinyur CIQ Ronnie Sahlberg, Jonathan Maple, dan Jeremy Allison adalah menempatkan angka-angka pasti di belakang posisi ini. Makalah mereka menunjukkan bahwa — dengan praktik rekayasa saat ini — hampir semua kernel vendor pada dasarnya tidak aman dan mengamankan kernel tersebut adalah hal yang mustahil.
Hal ini karena kernel vendor Linux dibuat dengan mengambil snapshot dari rilis Linux tertentu dan kemudian mem-backport perbaikan yang dipilih saat perubahan terjadi di pohon git upstream. Metode ini, dirancang di era ketika driver perangkat out-of-tree merajalela, bertujuan untuk meningkatkan stabilitas dan keamanan dengan memilih perubahan pada backport. Makalah ini mengkaji cara kerjanya dalam praktik dengan menganalisis tingkat perubahan dan jumlah bug di dalamnya Red Hat Enterprise Linux (RHEL) 8.8, kernel versi 4.18.0-477.27.1, membandingkannya dengan kernel upstream dari kernel.org.
Juga: Bagaimana Red Hat memanfaatkan AI untuk membuat hidup sysadmin lebih mudah
Meskipun pemrogram memeriksa RHEL 8.8 secara khusus, ini adalah masalah umum. Mereka akan menemukan hasil yang sama jika mereka memeriksanya SUSE, Ubuntuatau Debian Linux. Distro Linux yang dirilis secara bergulir seperti Lengkungan, GentooDan OpenSUSE Tumbleweed terus-menerus merilis pembaruan terkini, tetapi pembaruan tersebut tidak digunakan dalam bisnis.
Analisis mereka terhadap kernel RHEL 8.8 mengungkapkan 111,750 komitmen individu di log perubahan. Data ini, meskipun tidak merinci konten atau ukuran komitmen, memberikan pemahaman umum tentang proses backporting. Awalnya, terdapat tingkat backporting yang stabil, namun hal ini menurun sekitar bulan November 2021 dan kembali secara signifikan pada bulan November 2022, seiring dengan dirilisnya RHEL 8.5 dan RHEL 8.7. Pola ini, menurut penulis, mencerminkan pergeseran ke arah backporting yang lebih konservatif untuk meningkatkan stabilitas seiring berjalannya siklus rilis utama.
Pemeriksaan mereka menemukan 5.034 bug yang belum diperbaiki di RHEL 8.6; 4.767 bug yang belum diperbaiki di RHEL 8.7; dan 4.594 bug yang belum diperbaiki di RHEL 8.8.
Angka-angka ini mewakili bug yang diketahui dengan perbaikan upstream yang belum di-backport ke RHEL. Penghentian backporting lebih awal di RHEL 8.6 dan 8.7 telah menyebabkan lebih banyak bug yang belum diperbaiki dibandingkan dengan RHEL 8.8. Praktik Red Hat yang tidak memublikasikan perubahan kode sumber secara lengkap menambah kompleksitas, sehingga menghasilkan kemungkinan positif dan negatif palsu pada data yang harus digunakan oleh CIQ. Terlepas dari keterbatasan ini, CIQ melaporkan bahwa pemeriksaan manual menunjukkan akurasi yang tinggi dalam mengidentifikasi perbaikan yang hilang.
Juga: Ubuntu 24.04: Distro Linux baru yang hebat ini tidak hanya cepat – tetapi juga sebuah benteng
Bertentangan dengan asumsi bahwa bug dapat diperbaiki dengan cepat, banyak bug yang bertahan dalam jangka waktu lama sebelum diselesaikan. Penundaan ini berdampak pada kualitas kernel, karena proses back-porting yang melambat mengakibatkan semakin banyak bug yang diketahui dan belum diperbaiki, sehingga melemahkan stabilitas dan keamanan kernel seiring berjalannya waktu.
Sejak pengembang kernel Linux memilikinya diambil alih pengelolaannya Kerentanan dan Eksposur Umum (CVE) Linux, 270 CVE baru pada Maret 2024 dan 342 pada April 2024 telah dilaporkan. Ini telah diperbaiki di cabang git kernel Linux yang stabil.
Namun, banyaknya angka tersebut menggarisbawahi pentingnya penggunaan kernel upstream yang stabil untuk meningkatkan keamanan. Banyaknya CVE baru dan kurangnya periode embargo untuk perbaikan memerlukan pendekatan proaktif dari organisasi dalam mengevaluasi dan mengatasi kerentanan ini.
Selain itu, meskipun RHEL 8.8 belum dikembangkan secara aktif sejak akhir tahun 2022, sekitar 10% dari semua bug yang baru ditemukan masih memengaruhinya. Serangkaian perbaikan bug besar terakhir RHEL 8.8 hadir pada Mei 2023. Hal yang sama berlaku untuk distro Linux perusahaan lain yang lebih lama (tetapi masih didukung). Yang lebih meresahkan lagi, menurut CIQ: “Beberapa perbaikan hilang yang kami periksa secara eksplisit diungkapkan sebagai dapat dieksploitasi dari ruang pengguna.”
Juga: Linus Torvalds menghadapi pengembang jahat, kesalahan perangkat keras, dan sensasi AI yang ‘lucu’
Oleh karena itu, tim CIQ menyimpulkan model kernel vendor tradisional, yang ditandai dengan backporting selektif, memiliki kelemahan. Semakin banyaknya bug yang diketahui dan belum diperbaiki menunjukkan bahwa kernel vendor kurang aman dibandingkan kernel upstream yang stabil. Tim ini menganjurkan peralihan ke penggunaan cabang kernel stabil dari kernel.org untuk keamanan dan manajemen bug yang lebih baik.
Menurut penulis, “hal ini menciptakan insentif yang kuat” bagi pelanggan yang sadar akan keamanan untuk mengadopsi kernel yang stabil dibandingkan kernel khusus vendor. Mereka menegaskan, “Kami percaya bahwa satu-satunya cara realistis bagi pelanggan untuk mengetahui bahwa mereka menjalankan kernel seaman mungkin adalah dengan beralih ke cabang kernel yang stabil.”
Makalah ini bukan merupakan kritik terhadap insinyur kernel vendor Linux yang berdedikasi. Sebaliknya, ini merupakan undangan bagi industri untuk mendukung kernel stabil kernel.org sebagai solusi optimal jangka panjang. Pergeseran seperti ini akan memungkinkan para insinyur untuk lebih fokus memperbaiki bug khusus pelanggan dan meningkatkan fitur dibandingkan proses backporting yang memakan banyak tenaga.
Oleh karena itu, mereka mempunyai empat kesimpulan penting:
- Model kernel vendor rusak dan tidak dapat diperbaiki.
- Kernel vendor pada dasarnya tidak aman, dan kernel vendor yang distabilkan pada siklus akhir menjadi sangat rentan.
- Banyaknya bug terbuka yang diketahui membuat analisis atau pengklasifikasian semuanya menjadi tidak praktis.
- Kernel upstream yang stabil menawarkan perlindungan yang jauh lebih baik terhadap kerentanan keamanan dan bug dalam kode kernel.
Juga: Pintu belakang ini hampir menginfeksi Linux di mana-mana: Panggilan dekat XZ Utils
Lantas, apakah vendor akan melakukan hal ini? Terlepas dari semua alasan keamanan yang baik untuk berpindah ke kernel upstream yang stabil, terdapat argumen tandingan, yang intinya adalah sebagai berikut: Jika Anda selalu mengupgrade ke kernel terbaru, Anda mungkin juga mengalami masalah stabilitas. Sebuah program yang berfungsi baik dengan kernel 4.18.0-477.27.1 mungkin tidak berfungsi dengan 4.18.0-477.27.1.el8_8. Tentu saja, dalam kasus khusus tersebut, kernel yang lebih baru memperbaiki bug keamanan yang penting.
Semuanya bergantung pada tindakan penyeimbangan yang rumit antara keamanan dan stabilitas. Beberapa pengembang kernel Linux terkemuka dan CIQ beralih ke sisi keamanan. Kita akan melihat apa yang dikatakan komunitas vendor Linux lainnya.
