Kees Cook, mantan kepala administrator sistem kernel.org dan pemimpin Tim Keamanan Ubuntu yang sekarang bekerja di Google untuk mengamankan Android dan ChromeOS, menyatakan keprihatinannya tentang proses perbaikan bug di cabang stabil kernel saat ini. Setiap minggu, sekitar seratus perbaikan disertakan di cabang stabil, dan setelah jendela untuk menerima perubahan pada rilis berikutnya ditutup, jumlahnya mendekati seribu (pengelola menahan perbaikan hingga jendela ditutup, dan setelah pembentukan β -rc1β mereka mempublikasikan akumulasinya sekaligus), yang terlalu banyak dan membutuhkan banyak tenaga kerja untuk pemeliharaan produk berbasis kernel Linux.
Menurut Keys, proses penanganan kesalahan di kernel tidak mendapat perhatian dan kernel kekurangan setidaknya 100 pengembang tambahan untuk pekerjaan terkoordinasi di bidang ini. Pengembang kernel utama secara rutin memperbaiki bug, namun tidak ada jaminan bahwa perbaikan ini akan diterapkan ke varian kernel yang digunakan oleh pihak ketiga. Pengguna berbagai produk berbasis kernel Linux juga tidak memiliki cara untuk mengontrol bug mana yang diperbaiki dan kernel mana yang digunakan di perangkat mereka. Pada akhirnya, produsen bertanggung jawab atas keamanan produk mereka, tetapi dengan intensitas penerbitan perbaikan yang sangat tinggi di cabang kernel yang stabil, mereka dihadapkan pada pilihan - mem-porting semua perbaikan, mem-porting secara selektif yang paling penting, atau mengabaikan semua perbaikan. .
Solusi optimalnya adalah dengan memigrasikan perbaikan dan kerentanan yang paling penting saja, namun mengisolasi kesalahan tersebut dari alur umum adalah masalah utama. Jumlah terbesar masalah yang muncul adalah akibat penggunaan bahasa C, yang memerlukan kehati-hatian saat bekerja dengan memori dan pointer. Lebih buruk lagi, banyak patch kerentanan potensial tidak dilengkapi dengan pengidentifikasi CVE, atau diberi pengidentifikasi CVE beberapa saat setelah patch diterbitkan. Dalam lingkungan seperti itu, sangat sulit bagi produsen untuk memisahkan perbaikan kecil dari masalah keamanan yang penting. Menurut statistik, lebih dari 40% kerentanan diperbaiki sebelum CVE ditetapkan, dan rata-rata penundaan antara rilis perbaikan dan penugasan CVE adalah tiga bulan (yaitu, pada awalnya perbaikan dianggap sebagai bug biasa, tetapi hanya setelah beberapa bulan menjadi jelas bahwa kerentanan telah diperbaiki).
Akibatnya, tanpa cabang terpisah dengan perbaikan kerentanan dan tanpa menerima informasi tentang koneksi keamanan dari masalah tertentu, produsen produk berbasis kernel Linux dibiarkan terus mentransfer semua perbaikan dari cabang stabil terbaru. Namun pekerjaan ini membutuhkan banyak tenaga kerja dan menghadapi hambatan dari perusahaan karena ketakutan akan munculnya perubahan regresif yang dapat mengganggu pengoperasian normal produk.
Mari kita ingat bahwa menurut Linus Torvalds, semua kesalahan itu penting dan kerentanan tidak boleh dipisahkan dari jenis kesalahan lainnya dan dialokasikan ke kategori terpisah dengan prioritas lebih tinggi. Pendapat ini dijelaskan oleh fakta bahwa untuk pengembang biasa yang tidak berspesialisasi dalam masalah keamanan, hubungan antara perbaikan dan potensi kerentanan tidak jelas (untuk banyak perbaikan, hanya audit terpisah yang memungkinkan untuk memahami bahwa perbaikan tersebut berkaitan dengan keamanan. ). Menurut Linus, spesialis keamanan dari tim yang bertanggung jawab memelihara paket kernel di distribusi Linux harus dilibatkan dalam mengidentifikasi potensi kerentanan dari aliran tambalan umum.
Kees Cook percaya bahwa satu-satunya solusi untuk menjaga keamanan kernel dengan biaya jangka panjang yang wajar adalah dengan memindahkan para insinyur yang terlibat dalam porting perbaikan ke kernel lokal menjadi upaya bersama dan terkoordinasi untuk menjaga perbaikan dan kerentanan di kernel utama (upstream). ). Dalam bentuknya yang sekarang, banyak produsen tidak menggunakan versi kernel terbaru dalam produk mereka dan melakukan backport perbaikan sendiri, yaitu dengan melakukan perbaikan sendiri. Ternyata para insinyur di perusahaan yang berbeda menduplikasi pekerjaan satu sama lain, sehingga memecahkan masalah yang sama.
Misalnya, jika 10 perusahaan, yang masing-masing memiliki satu insinyur yang mendukung perbaikan yang sama, menugaskan kembali para insinyur tersebut untuk memperbaiki bug di hulu, maka alih-alih mem-backport satu perbaikan, mereka dapat memperbaiki 10 bug yang berbeda untuk kepentingan bersama atau bergabung dalam peninjauan usulan perbaikan. mengubah dan mencegah kode buggy dimasukkan ke dalam kernel. Sumber daya juga dapat dicurahkan untuk menciptakan alat baru untuk menguji dan menganalisis kode yang memungkinkan deteksi dini terhadap kelompok kesalahan umum yang muncul berulang kali.
Kees Cook juga menyarankan untuk lebih aktif menggunakan pengujian otomatis dan fuzzing secara langsung dalam proses pengembangan kernel, menggunakan sistem integrasi berkelanjutan dan meninggalkan manajemen pengembangan kuno melalui email. Saat ini, pengujian yang efektif terhambat oleh fakta bahwa proses pengujian utama dipisahkan dari pengembangan dan dilakukan setelah rilis dibuat. Keys juga merekomendasikan penggunaan bahasa yang memberikan tingkat keamanan lebih tinggi, seperti Rust, saat mengembangkan untuk mengurangi jumlah kesalahan.
Sumber: opennet.ru