hadicanim
Aktif Üye
Linux: Çekirdekteki CVE bolluğunun eleştirisi, nedenleri ve sonuçları
Her türden yönetici ve geliştirici birkaç aydır yüksek sesle şikayette bulunuyor: Yıllar boyunca Linux çekirdeğindeki haftada yalnızca dört ila altı güvenlik açığına yanıt vermek zorunda kaldılar, ancak Şubat ayından bu yana bu sayı on kattan fazla oldu. Önde gelen çekirdek geliştiricileri yakın zamanda derslerde ve tartışma gruplarında CVE etiketlerinin bolluğu üzerine yeni durumun iyi bir şey olduğunu vurguladılar. Bu konuda şikayette bulunan distribütörlerin, şikayetleriyle daha önce güvenlik sorununu ciddiye almadıklarını ve dolayısıyla açıkça güvenlik düzeltmesi olarak tanımlanmayan önemli düzeltmeleri göz ardı ettiklerini göstereceklerini öne sürdüler.
Reklamcılık
Görünüşe göre bazı büyük şirketler bunun farkına vardı ve yeni durumu kendileri ve müşterileri için daha katlanılabilir hale getirmek için çeşitli faaliyetler düşünüyorlar. Bu aynı zamanda hobi yöneticilerine de bir noktada fayda sağlayacaktır. Ancak bu, çeşitli cephelerde muazzam miktarda çalışma gerektirdiğinden, daha yakından bakıldığında biraz zaman alabileceğini gösteriyor.
Şubat ayından bu yana 3000'den fazla CVE
Durumun değişmesinin nedeni Linux adı verilen çekirdeğin geliştiricileridir. Onlarca yıldır CVE (Ortak Güvenlik Açıkları ve Etkilenmeler) gibi etiketleri zerre kadar umursamamışlardı; Değişikliklerin güvenlik yönünü gizlemek için defalarca CVE kimliklerini gizlediler veya hatta bunları yama açıklamalarından kaldırdılar. Ancak dış taraflara şüpheli çekirdek güvenlik açıkları için giderek daha fazla CVE verildiğinden, geliştiriciler, diğer açık kaynaklara benzer şekilde, Linux için CVE tahsisini kendileri kontrol etmek amacıyla yılın başında bir CNA (CVE Numaralandırma Yetkilisi) olmaya zorlandılar. Daha önce projeler.
Sorumlu Linux geliştiricileri, Şubat ayından bu yana yaklaşık 3.375 CVE etiketi yayınladı; bunların arasında, şirketin kurulduğu dönemdeki spesifikasyonlar nedeniyle önceki yıllarda giderilen her türlü güvenlik açığı da bulunuyor. İtirazların ardından sorumlular bu CVE'lerin yaklaşık yüz kadarını geri çekti. Dışarıdan pek çok kişi ve aynı zamanda resmi çekirdeğin her türden geliştiricisi, diğer birçok CVE'nin de gerçek bir güvenlik açığının yamalanmaması nedeniyle haksız olduğunu eleştiriyor.
Ne kadar küçük olursa olsun güvenlik açıklarına yönelik CVE'ler zorunludur
Her şeyin arkasındaki ana itici güç ve ikinci en önemli çekirdek geliştiricisi olan Greg Kroah-Hartman, bu iddialara her zaman aynı şekilde tepki veriyor: CVE tahsisine ilişkin yönergeler, kendisini ve diğer sorumlu tarafları bir görevlendirmek zorunda bırakacaktır. Bunları ortadan kaldıran herhangi bir potansiyel güvenlik açığına CVE etiketi ekleyin. Ayrıca insanların Linux'u çeşitli şekillerde kullandıklarını ve bunun da görünüşte zararsız bir düzeltmenin belirli kullanım alanlarında gerçekten güvenlikle ilgili olup olmadığını tahmin etmeyi çok zorlaştırdığını belirtiyor.
Ayrıntılarla ilgilenenler için, Kroah-Hartman'ın bu yönleri daha ayrıntılı olarak açıkladığı ve çok sayıda başka içgörü sağladığı yakın tarihli bir konuşmanın sunumunu ve videosunu öneriyoruz. Haftada yaklaşık 55 CVE ile çekirdeğin lider olmadığını belirtiyor: Örneğin WordPress, haftada 110'un üzerinde yayın yapıyor. Ayrıca prosedüre de giriyor: Tahsis, düzeltmelerin kullanıcılara yönelik yeni çekirdek sürümlerine dahil edilmesinden yalnızca birkaç gün veya hafta sonra gerçekleşir.
Üç kişi CVE vermeyi kabul etmelidir
Sorumlular, yalnızca halihazırda dahil olan üç geliştiricinin kamuya açık inceleme sürecinde kendilerine oy vermesi durumunda CVE'leri güvenlik açıklarına ödüllendirir. Değişikliklerin gerçek programcıları veya ilgili çekirdek kodunun bakımcıları bu sürece dahil değildir – ancak bunlar genellikle güvenlik uzmanları değildir ve Kroah-Hartman'ın yakın zamanda başka bir yerde vurguladığı gibi bakımcılar genellikle zaten sınırlarının içinde veya sınırlarının ötesindedir. Uzun yıllardan beri olduğu gibi, bilinen boşluklardan kaçınmak için kullanıcılara hala en son kararlı veya uzun vadeli çekirdek serisinin en son sürümünü kullanmalarını tavsiye ediyor.
İki kötülük arasındaki seçim
Bir ders slaytında Kroah-Hartman, on yılı aşkın bir süredir büyük kararlılığıyla Linux çekirdeğini önemli ölçüde daha güvenli hale getiren Kees Cook'tan da alıntı yapıyor. Ona göre, en güvenli çekirdek konusunda endişe duyan kullanıcılar yalnızca iki yaklaşım arasında seçim yapma hakkına sahiptir: ya güncel bir serinin en son sürümünü kullanın ya da sadece her bir CVE girişini daha ayrıntılı olarak inceleyin; böylece düzeltmeleri bunlar için uygulayabilirsiniz. Kullanılan çekirdekle ilgili güvenlik açıkları, belirli uygulama alanıyla ilgilidir. Her ikisi de çok fazla çalışmaya ve rahatsızlığa neden olur; örneğin yeniden başlatmanın zor veya imkansız olduğu durumlarda; Cook'a göre herkesin kendi ortamında iki yaklaşımdan hangisinin daha kolay olduğunu kendi gözleriyle görmesi gerekiyor.
Cook'un sözleri, yakın zamanda Linux Tesisatçıları Konferansı'nda gerçekleştirilen yeni çekirdek CVE durumuyla ilgili açık bir tartışmadan geliyor. Linux'u dahili olarak veya ürünlerinde kullanan çok sayıda büyük ve küçük şirketten çekirdek geliştiricileri katıldı. Grup çok farklı alanlara değindi ve her türlü soruyu yanıtsız bıraktı. Yine de şu ya da bu şey öngörülebilir.
Tehdit modelleri işbirliğini mümkün kılmayı amaçlamaktadır
Çeşitli şirketlerden geliştiriciler, bir avuç tehdit modelini tanımlama konusunda oldukça spesifik konuştular. İlgili taraflar daha sonra açık kaynak ilkelerine göre bir işbölümünde CVE'leri inceleyebilir ve her biri için bunun ilgili tehdit modeliyle ilgili olup olmadığını belirleyebilir.
Böyle bir tehdit modeli “bulut sağlayıcısı” olabilir: tamamen güvenilir kullanıcılara sahip modern ARM64 ve x86-64 sunucu donanımı, ancak güvenilmez yazılıma sahip sanal makineler. Amazon/AWS, Google, IBM ve Microsoft gibi şirketler, bunu şirket içinde yapmak yerine, hangi CVE'lerin bu tehdit modeliyle ilgili olduğunu belirlemek için birlikte çalışabilir. Bu ve benzeri analizlerin sonuçları daha sonra CVE'lerle ilgili tüm ayrıntıları merkezi olarak bir araya getiren JSON dosyalarına geri aktarılabilir.
Esnek kurumsal Linux için çok çaba
Ele alınan diğer tehdit modelleri Otomotiv veya Kurumsal Linux'tur. İkincisi, eğer gerçekleşirse, muhtemelen donanım desteği ve uygulama alanları açısından açıkça tanımlanmış Linux dağıtımları için daha uygundur. Başka bir deyişle Amazon/AWS, Google, Meta, Microsoft, Oracle, Red Hat veya SuSE'nin şirket içinde sunduğu veya kullandığı ürünler. Onlar için bile CVE'leri sınıflandırmak büyük bir çaba gerektirecektir. Debian'ınkiler gibi çok daha fazla işlev ve sürücüyle derlenmiş çekirdekleri dahil etmek isterseniz, çaba yine önemli ölçüde artacaktır; muhtemelen hiç kimsenin gerekli işi gönüllü olarak yapamayacağı veya bunu yapması için birine para ödeyemeyeceği noktaya kadar.
İlgili bir hususa yalnızca tartışma grubunda değinildi, ancak çevrede tartışıldı: CVE'den etkilenen kodun kullanılan çekirdekte (doğrudan veya bir modülde) bulunup bulunmadığını kontrol eden açık kaynaklı araçların eksikliği. yerel olması kolayca kaldırılabilir veya engellenebilir. En azından Google, Oracle ve SuSE, bölgede bilindiği gibi bu tür araçları uzun süredir şirket içinde kullanıyor. Birisinin böyle bir aracı, gelecekte durum göz önüne alındığında bir araya gelmek için açık kaynak lisansı altında yayınlaması muhtemelen sadece bir zaman meselesidir.
Canlı yama konusuna değinildi çünkü bu konuda da hala cevaplanmamış sorular var. Bu tekniği kullanarak CVE düzeltmelerinin tamamını veya en azından büyük bir kısmını çalışma zamanında uygulamak belki teorik olarak düşünülebilir ancak pratikte uygulanması zor olacaktır: bu tür karmaşık canlı yamaları oluşturmak ve doğrulamak çok emek ve zaman gerektirir. Sonuçta, bu muhtemelen birkaç hafta boyunca yeniden başlatmalardan kaçınmayı mümkün kılacaktır, ancak aylarca bu mümkün olmayacaktır.
Ancak tartışma grubundaki bir katılımcı, birçok CVE'nin, sertifikasyon düzenlemeleri nedeniyle güncellemelerin zor ve pahalı olduğu alanlarda (örneğin hastanelerde Linux kullanıldığında) büyük bir sorun olduğunu belirtti. Kroah-Hartman, ABD ve AB yasa yapıcılarının sorunun farkına vardıklarını ve çözümler üzerinde çalıştıklarını ancak bunun zaman aldığını açıkladı.
Tartışmanın kaydını konferansın canlı akışında bulabilirsiniz; Ancak başlangıçtan kısa bir süre sonra birkaç dakikalık ses eksik.
(DMK)