Kapsamlı yeni bir araştırma, büyük açık kaynaklı yazılım (OSS) projelerinde bellek açısından güvenli olmayan kodun yaygın ve rahatsız edici kullanımına ilişkin yeni ayrıntıları ortaya çıkardı.
Ancak, uzun zamandır bilinen bir sorunla ilgili yeni bir bakış açısının yazılım ortamında herhangi bir acil değişikliğe yol açması ihtimali, kod tabanlarını tamamen bellek güvenli kodla yeniden yazmanın ne kadar büyük, maliyetli ve karmaşık bir iş olduğu göz önüne alındığında, hâlâ zayıf kalıyor.
C ve C++ gibi bellek açısından güvenli olmayan programlama dilleri, programcıların koddaki bellekle ilgili işlevler üzerinde daha doğrudan kontrole sahip olmasına olanak tanır; bu da genellikle arabellek taşmaları ve serbest kullanım sonrası hataları gibi çok yaygın uygulama güvenliği sorunlarına yol açabilir. Bu tür kusurlar, modern uygulama yazılımındaki tüm güvenlik açıklarının büyük bir bölümünü temsil etmektedir. Buna karşılık, bellek açısından güvenli diller (bunların en yaygın örnekleri Rust, Python, Java ve Go’dur), bellekle ilgili yaygın hataları azaltmak için yerleşik çalışma zamanı ve derleme zamanı kontrolleri gibi korumalar sunar.
Çoğu OSS Projesi Bellek-Güvensiz Kod İçerir
ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), FBI ve Avustralya Siber Güvenlik Merkezi ve Kanada Siber Güvenlik Merkezi’ndeki meslektaşlarıyla birlikte bu hafta bu hafta sonuçları özetleyen bir rapor yayınladı OSS’de bellek açısından güvenli olmayan kod kullanımına ilişkin araştırmaları hakkında.
Bulgular, rahatsız edici olsa da, neredeyse tüm modern kod tabanlarında bellek açısından güvenli olmayan dillerin yaygın kullanımına ilişkin geçmiş veriler göz önüne alındığında tamamen beklenmedik değil. Araştırma yazarlarının incelediği 172 büyük açık kaynaklı projenin yüzde elli ikisi, bellek açısından güvenli olmayan bir dilde yazılmış kod içeriyordu. Tüm projelerdeki toplam kod satırlarının yarısından fazlası (%55) bellek açısından güvenli olmayan bir dilde yazılmıştı ve en büyük suçlular daha büyük projelerdi.
Örneğin Linux’taki toplam kod satırlarının yaklaşık %95’i bellek açısından güvenli değildir. MySQL Server için bu sayı %84’tür; TensorFlow için %64’tür; Zephyr için %84’tür; ve Chromium için %51’dir. Ortalama olarak, en büyük 10 açık kaynak projesindeki toplam kod satırlarının %26’sı bellek açısından güvenli olmayan koddan oluşuyordu. Bellek açısından güvenli dillerde yazılmış projeler bile güvenli olmayan bileşenlere bağımlılıktan dolayı risk altındaydı.
Raporda, “Analiz edilen çoğu kritik açık kaynak projesi, hatta hafıza açısından güvenli dillerde yazılmış olanlar bile, potansiyel olarak hafıza güvenliği açıkları içeriyor” ifadesine yer verildi. “Bu, bellek açısından güvenli olmayan dillerin doğrudan kullanılmasından veya bellek açısından güvenli olmayan diller kullanan projelere dış bağımlılıktan kaynaklanabilir.”
Ayrıca, uygulamalardaki işlevsel gereksinimleri karşılamak için bellek güvenliği özelliklerini devre dışı bırakma eğilimi ve sıklıkla bu gereksinim, aksi takdirde bellek güvenli olan dilleri kullanmanın faydalarını etkisiz hale getirebilir.
Raporun yazarları, “Bu sınırlamalar, bellek açısından güvenli programlama dillerinin, güvenli kodlama uygulamalarının ve güvenlik testlerinin sürekli olarak dikkatli bir şekilde kullanılmasının gerekliliğini vurgulamaktadır” dedi.
CISA Önceki OSS Verileriyle Tutarlı
Bulgular, hafıza açısından güvenli olmayan dillerin kullanımına bağlı kapsamlı sorunları inceleyen çok sayıda önceki çalışmayla tutarlıdır.
Ve gerçekten de, sorunun her yerde bulunmasına ilişkin endişeler yıllar boyunca değişim çağrılarına yol açtı. En sonuncusu Beyaz Saray’dan Şubat 2024 teknik raporu endüstri paydaşlarını yapı taşlarına geri dönmeye ve tüm yazılımlarda bellek güvenli kod kullanmaya yeniden başlamaya çağırdı. 2022’de ABD Ulusal Güvenlik Ajansı (NSA), yazılım üreticilerini ve yazılım geliştiren tüm kuruluşları hafıza açısından güvenli dilleri benimsemeyi düşünün modern kod tabanlarında bellek yönetimiyle ilgili yazılım sorunlarından kaynaklanan riski azaltmak için. Yıllardır konunun üzerinde durmaya devam edilmesi, bazı değişiklikleri teşvik ettiancak çoğu kişi, hafıza açısından güvenli dillere tam ölçekli bir geçişin gerçekleşmesinin yıllar, hatta on yıllar alacağını düşünüyor.
“Bellek güvenli kodu benimsemek zordur, çünkü bir programlama dilini değiştirmek genellikle mevcut kodun tamamen yeniden yazılmasını gerektirir,” diyor OX Security’nin CEO’su ve Kurucu Ortağı Neatsun Ziv. Önemli ekonomik teşvikler olmadan böylesine büyük bir yenilemeyi üstlenmek için gereken maliyet ve çaba, muhtemelen herhangi bir değişikliği yavaş bir süreç haline getirecektir.
Dünyayı Hafıza açısından Güvenli Hale Getirmek: Büyük ve Karmaşık Bir Zorluk
OpenSSF genel müdürü Omkhar Arasaratnam, bellek güvenliği sorunlarının açık veya kapalı kaynaklı yazılımlar için özel bir sorun olmadığını söylüyor. Bu, genel olarak tüm modern yazılımlar için bir sorundur.
“Günümüzde JavaScript, Python ve Java gibi bellek açısından güvenli birçok dil mevcut, ancak yazılım mühendisleri performans veya düşük düzeyli donanım erişimi için sıklıkla C/C++ gibi bellek açısından güvenli olmayan eski dilleri kullanıyor” diyor.
Ayrıca Rust, son yıllarda düşük seviyeli sistem programlama için C/C++’ya uygun bir alternatif olarak ortaya çıkmış olsa da, Rust’un uygun olmadığı birçok gömülü sistem ve güvenlik açısından kritik uygulamaların bulunduğunu da ekliyor.
Arasaratnam, “Bellek açısından güvenli olmayan bir dilde bellek açısından güvenli kod yazmak kesinlikle mümkün olsa da, 25 yıllık CVE’ler bize bunun pek olası olmadığını söylüyor” diyor. “İnsanların kötü programcı olduğu söylenemez ama hafıza açısından güvenli olmayan bir dilde savunma amaçlı olarak hafıza açısından güvenli kod yazmak çok zordur” diye belirtiyor. Yeni projeler bellek açısından güvenli dilleri benimsedikçe, niş uygulamalar dışındaki tüm uygulamalarda bellek açısından güvenli olmayan dillerin kullanımının zamanla azalmasını bekleyebilirsiniz.
Synopsys Software Integrity Group’ta yazılım tedarik zinciri risk stratejisi başkanı Tim Mackey, yeni raporun Kubernetes ve WordPress gibi bazı büyük açık kaynaklı yazılım projelerinin bellek güvenli bir dilde nasıl yazıldığını göstermede iyi bir iş çıkardığını söylüyor. Ancak, keşfedilmemiş başka sorunlar da olduğunu söylüyor. Örneğin, GitHub’daki yeni projelerde bellek güvenli dillerin kullanılıp kullanılmadığını ve bellek güvenli kitaplıkların daha büyük projelerde bağımlılık olarak kullanılıp kullanılmadığını bilmek ilginç olurdu.
“Bellek güvenli diller konusunda farkındalığın arttığını rahatlıkla söyleyebiliriz, ancak bu, eski dillerin yerini alacak bir oranda mı artıyor? Örneğin, yeni gömülü yazılım çözümlerinin yaratıcıları C++ veya Rust kullanıyor mu ve hangi ölçüde?”