Bellek güvenli kodunu kullanmayan en kritik açık kaynak projeleri


CISA

ABD Siber Güvenlik ve Altyapı Güvenlik Ajansı (CISA), 172 önemli açık kaynaklı projeyi inceleyen ve bunların bellek kusurlarına karşı hassas olup olmadıklarını inceleyen bir araştırma yayınladı.

CISA, Federal Soruşturma Bürosu (FBI) ve Avustralyalı (ASD, ACSC) ve Kanadalı örgütlerin (CCCS) ortak imzasıyla hazırlanan rapor, Aralık 2023’te yayınlanan ve bellek güvenli kodun önemi konusunda farkındalık yaratmayı amaçlayan ‘Bellek Güvenli Yol Haritaları Davası’nın devamı niteliğindedir.

Bellek güvenliği

Bellek açısından güvenli diller, arabellek taşmaları, boş kullanımdan sonra kullanım ve diğer bellek bozulması türleri gibi yaygın bellekle ilgili hataları önlemek için tasarlanmış programlama dilleridir.

Bunu, güvenli bellek ayırma ve ayırma mekanizmalarını uygulamak için programcıya güvenmek yerine belleği otomatik olarak yöneterek başarırlar.

Güvenli dil sisteminin modern bir örneği, Rust’un veri yarışlarını ortadan kaldıran ödünç alma denetleyicisidir. Golang, Java, C# ve Python gibi diğer diller, çöp toplama yoluyla belleği yönetir ve kötüye kullanımı önlemek için boş belleği otomatik olarak geri alır.

Bellek açısından güvenli olmayan diller, yerleşik bellek yönetimi mekanizmaları sağlamayan, geliştiriciye bu sorumluluğu yükleyen ve hata olasılığını artıran dillerdir. Bu tür durumların örnekleri C, C++, Objective-C, Assembly, Cython ve D’dir.

Yaygın olarak kullanılan açık kaynak kodu güvensiz

Raporda, yaygın olarak kullanılan 172 açık kaynaklı projeyi inceleyen bir araştırma sunuluyor ve bunların yarısından fazlasının bellek açısından güvenli olmayan kod içerdiği tespit ediliyor.

Raporda sunulan temel bulgular şöyle özetleniyor:

  • Analiz edilen kritik açık kaynak projelerinin %52’si bellek açısından güvenli olmayan dillerde yazılmış kod içeriyor.
  • Bu projelerdeki toplam kod satırlarının (LoC) %55’i bellek açısından güvenli olmayan dillerde yazılmıştır.
  • En büyük projeler orantısız bir şekilde hafıza açısından güvenli olmayan dillerde yazılmaktadır.
  • Toplam LoC’ye göre en büyük on projeden her biri %26’nın üzerinde bellek açısından güvenli olmayan LoC oranına sahiptir.
  • Bu büyük projelerde bellek açısından güvenli olmayan LoC’nin ortalama oranı %62,5 olup, dört projede bu oran %94’ü aşmaktadır.
  • Bellek açısından güvenli dillerde yazılan projeler bile genellikle bellek açısından güvenli olmayan dillerde yazılan bileşenlere bağlıdır.

İncelenen gruptan dikkate değer bazı örnekler Linux (güvenli olmayan kod oranı %95), Tor (güvenli olmayan kod oranı %93), Chromium (güvenli olmayan oran %51), MySQL Server (güvenli olmayan oran %84), glibc (oran %85), Redis (oran %85), SystemD (%65) ve Electron (%47).

Bulguların özeti
Bulguların özeti
Kaynak: CISA

CISA, yazılım geliştiricilerinin genellikle kaynak kısıtlamaları ve performans gereksinimleri gibi bellek açısından güvenli olmayan dilleri kullanmaya zorlayan birçok zorlukla karşı karşıya kaldıklarını açıklıyor.

Bu özellikle ağ oluşturma, şifreleme ve işletim sistemi işlevleri gibi düşük düzeyli işlevleri uygularken geçerlidir.

Raporda CISA, “Birçok kritik açık kaynak projesinin kısmen bellek açısından güvenli olmayan dillerde yazıldığını gözlemledik ve sınırlı bağımlılık analizi, projelerin bellek açısından güvenli olmayan dillerde yazılmış kodu bağımlılıklar yoluyla devraldığını gösteriyor” diye açıklıyor.

“Performans ve kaynak kısıtlamalarının kritik faktörler olduğu durumlarda, bellek açısından güvenli olmayan dillerin kullanılmaya devam ettiğini gördük ve bekliyoruz.”

Ajans ayrıca geliştiricilerin, belirli gereksinimleri karşılamak adına, yanlışlıkla veya bilerek bellek güvenliği özelliklerini devre dışı bırakmalarının, teorik olarak daha güvenli yapı taşları kullanılsa bile risklere yol açtığını vurguluyor.

Son olarak CISA, yazılım geliştiricilerin Rust, Java ve GO gibi bellek açısından güvenli dillerde yeni kod yazmalarını ve mevcut projeleri, özellikle de kritik bileşenleri bu dillere aktarmalarını önerir.

Ayrıca, bellek güvenliği sorunlarını tespit etmek ve ele almak için güvenli kodlama uygulamalarının takip edilmesi, bağımlılıkların dikkatli bir şekilde yönetilmesi ve denetlenmesi ve statik analiz, dinamik analiz ve bulanıklık testi dahil sürekli testlerin gerçekleştirilmesi önerilir.



Source link