Kees memasak Saya membuat posting blog di mana telah menimbulkan kekhawatiran tentang proses perbaikan bug sedang berlangsung di cabang stabil kernel Linux dan apakah itu? sebutkan bahwa minggu demi minggu sekitar seratus koreksi disertakan pada cabang stabil, yang terlalu banyak dan membutuhkan banyak usaha untuk memelihara produk berbasis kernel Linux.
Menurut Kees, proses penanganan kesalahan kernel dilewati dan kernel tidak memiliki setidaknya 100 pengembang tambahan untuk bekerja secara terkoordinasi di bidang ini. Juga menyebutkan bahwa pengembang kernel utama secara teratur memperbaiki bug, tetapi tidak ada jaminan bahwa perbaikan ini akan dibawa ke varian kernel pihak ketiga.
Dalam melakukannya, ia menyebutkan bahwa pengguna berbagai produk berbasis kernel Linux juga tidak memiliki cara untuk mengontrol bug mana yang diperbaiki dan kernel mana yang digunakan pada perangkat mereka. Pada akhirnya, vendor bertanggung jawab atas keamanan produk mereka, tetapi dihadapkan dengan tingkat patch yang sangat tinggi pada cabang kernel yang stabil, mereka dihadapkan pada pilihan untuk memigrasikan semua patch, secara selektif memigrasikan yang paling penting, atau mengabaikan semua patch. .
Pengembang kernel hulu dapat memperbaiki bug, tetapi mereka tidak memiliki kendali atas apa yang dipilih vendor hilir untuk dimasukkan ke dalam produk mereka. Pengguna akhir dapat memilih produk mereka, tetapi mereka umumnya tidak memiliki kendali atas bug mana yang diperbaiki atau kernel mana yang digunakan (masalah itu sendiri). Pada akhirnya, vendor bertanggung jawab untuk menjaga keamanan inti produk mereka.
Kees memasak menyarankan bahwa solusi optimal adalah mentransfer hanya perbaikan dan kerentanan yang paling penting, tetapi masalah utamanya adalah untuk memisahkan kesalahan ini dari aliran umum, karena sebagian besar masalah yang muncul adalah konsekuensi dari penggunaan bahasa C, yang membutuhkan banyak perhatian saat bekerja dengan memori dan pointer.
Lebih buruk lagi, banyak perbaikan kerentanan potensial tidak ditandai dengan pengidentifikasi CVE atau tidak menerima pengidentifikasi CVE beberapa saat setelah patch dirilis.
Dalam lingkungan seperti itu, sangat sulit bagi produsen untuk memisahkan perbaikan kecil dari masalah keamanan utama. Menurut statistik, lebih dari 40% kerentanan dihapus sebelum penugasan CVE, dan rata-rata penundaan antara rilis perbaikan dan penugasan CVE adalah tiga bulan (yaitu, pada awalnya, a menganggap solusi sebagai kesalahan umum,
Sebagai hasilnya, tidak memiliki cabang terpisah dengan perbaikan untuk kerentanan dan tidak menerima informasi tentang koneksi dengan keamanan masalah ini atau itu, produsen produk berbasis kernel Linux harus terus mentransfer semua perbaikan cabang baru yang stabil. Tetapi pekerjaan ini padat karya dan menghadapi perlawanan dari perusahaan karena ketakutan akan perubahan regresif yang dapat mengganggu operasi normal produk.
Kunci Masak percaya bahwa satu-satunya solusi untuk menjaga kernel tetap aman dengan biaya yang wajar dalam jangka panjang adalah dengan mem-porting para insinyur tambalan untuk membangun kernel gilal untuk bekerja sama dalam cara yang terkoordinasi untuk menjaga patch dan kerentanan di kernel upstream. Seperti berdiri, banyak vendor tidak menggunakan versi kernel terbaru dalam produk mereka dan perbaikan backport sendiri, yaitu, ternyata para insinyur dari perusahaan yang berbeda menduplikasi pekerjaan satu sama lain, memecahkan masalah yang sama.
Misalnya, jika 10 perusahaan, masing-masing dengan seorang insinyur yang mendukung perbaikan yang sama, mengarahkan para insinyur ini untuk memperbaiki bug ke hulu, alih-alih memigrasikan satu perbaikan, mereka dapat memperbaiki 10 bug yang berbeda untuk keuntungan keseluruhan atau berkumpul untuk meninjau bug. . Dan hindari memasukkan kode buggy di kernel. Sumber daya juga dapat digunakan untuk membuat analisis kode baru dan alat pengujian yang secara otomatis akan mendeteksi pada tahap awal kelas kesalahan tipikal yang muncul berulang kali.
Kunci Masak juga mengusulkan untuk lebih aktif menggunakan pengujian dan fuzzing otomatis langsung dalam proses pengembangan kernel, gunakan sistem integrasi berkelanjutan dan tinggalkan manajemen pengembangan kuno melalui email.
sumber: https://security.googleblog.com