Kees Aşçı İçinde bir blog yazısı yapıyorum hata düzeltme süreciyle ilgili endişeleri dile getirdi Linux çekirdeğinin kararlı dallarında devam ediyor ve bu her hafta yaklaşık yüz düzeltmenin dahil edildiğinden bahsedin Linux çekirdeği tabanlı ürünleri korumak için çok fazla ve çok çaba gerektiren kararlı dallarda.
Kees'e göre, çekirdek hata işleme süreci atlanır ve çekirdek en az 100 ek geliştiriciden yoksun Bu alanda koordineli bir şekilde çalışmak. Ayrıca, büyük çekirdek geliştiricilerinin hataları düzenli olarak düzelttiğinden de bahsetmiştik, ancak bu düzeltmelerin üçüncü taraf çekirdek varyantlarına taşınacağının garantisi yok.
Bunu yaparken, çeşitli Linux çekirdeği tabanlı ürünlerin kullanıcılarının, cihazlarında hangi hataların düzeltildiğini ve hangi çekirdeğin kullanıldığını kontrol etme yollarının da olmadığını belirtiyor. Sonuçta, satıcılar ürünlerinin güvenliğinden sorumludur, ancak kararlı çekirdek dallarında çok yüksek oranda yamalarla karşı karşıya kaldıklarında, tüm yamaları geçirme, en önemlilerini seçici olarak geçirme veya tüm yamaları görmezden gelme seçenekleriyle karşı karşıya kaldılar. .
Yukarı akış çekirdek geliştiricileri, hataları düzeltebilir, ancak bir alt satıcının ürünlerine dahil etmeyi seçtikleri üzerinde hiçbir kontrolleri yoktur. Son kullanıcılar ürünlerini seçebilir, ancak genellikle hangi hataların düzeltileceği veya hangi çekirdeğin kullanılacağı (kendi başına bir sorun) üzerinde kontrolleri yoktur. Sonuçta, satıcılar ürün çekirdeklerini güvende tutmaktan sorumludur.
Kees Aşçı en uygun çözümün yalnızca en önemli düzeltmeleri ve güvenlik açıklarını aktarmak olacağını öne sürüyor, ancak asıl sorun bu hataları genel akıştan ayırmaktır, çünkü ortaya çıkan sorunların çoğu, bellek ve işaretçilerle çalışırken çok fazla özen gerektiren C dili kullanımının bir sonucudur.
Daha da kötüsü, birçok olası güvenlik açığı düzeltmesi CVE tanımlayıcılarıyla etiketlenmez veya yama yayınlandıktan bir süre sonra bir CVE tanımlayıcısı almaz.
Böyle bir ortamda, üreticilerin küçük düzeltmeleri büyük güvenlik sorunlarından ayırması çok zordur. İstatistiklere göre, güvenlik açıklarının %40'ından fazlası CVE atamasından önce kaldırılır ve ortalama olarak bir düzeltme sürümü ile CVE ataması arasındaki gecikme üç aydır (yani başlangıçta, bir çözümü yaygın bir hata olarak algılar,
Sonuç olarak, güvenlik açıkları için düzeltmeler içeren ayrı bir şubeye sahip olmamak ve bu veya bu sorunun güvenliği ile bağlantı hakkında bilgi almamak, Linux çekirdeği tabanlı ürün üreticilerinin tüm düzeltmeleri sürekli olarak aktarması gerekir. yeni istikrarlı dalların. Ancak bu iş, emek yoğundur ve ürünün normal çalışmasını bozabilecek gerileyen değişikliklerin korkuları nedeniyle şirketlerin direnişiyle karşı karşıyadır.
Tuşlar Aşçı Çekirdeği makul bir maliyetle uzun vadede güvende tutmanın tek yolunun yama mühendislerini taşımak olduğuna inanıyor. çılgın çekirdek yapılarınakoordineli bir şekilde birlikte çalışmak yukarı akış çekirdeğindeki yamaları ve güvenlik açıklarını korumak için. Halihazırda, birçok satıcı ürünlerinde en son çekirdek sürümlerini ve backport düzeltmelerini kendi başlarına kullanmazlar, yani farklı şirketlerden mühendislerin birbirlerinin çalışmalarını kopyalayarak aynı sorunu çözdüğü ortaya çıktı.
Örneğin, her biri aynı düzeltmeleri destekleyen bir mühendise sahip 10 şirket, bu mühendisleri tek bir düzeltmeyi taşımak yerine hataları yukarı akış yönünde düzeltmeye yönlendirirse, genel fayda için 10 farklı hatayı düzeltebilir veya hataları gözden geçirmek için bir araya gelebilirler. . Ve çekirdeğe buggy kodu eklemekten kaçının. Kaynaklar, tekrar tekrar ortaya çıkan tipik hata sınıflarını erken bir aşamada otomatik olarak algılayacak yeni kod analizi ve test araçları oluşturmak için de kullanılabilir.
Tuşlar Aşçı ayrıca otomatik test ve fuzzing'i daha aktif bir şekilde kullanmayı önerir. doğrudan çekirdek geliştirme sürecinde, sürekli entegrasyon sistemlerini kullanın ve e-posta yoluyla arkaik geliştirme yönetiminden vazgeçin.
kaynak: https://security.googleblog.com