Kapsamlı yeni bir çalışma, büyük açık kaynaklı yazılım (OSS) projelerinde bellek açısından güvenli olmayan kodun yaygın ve sorunlu kullanımına ilişkin yeni ayrıntıları ortaya çıkardı.
Bununla birlikte, kod tabanlarını tamamen bellek açısından güvenli kodda yeniden yazma görevinin ne kadar devasa, maliyetli ve karmaşık olduğu göz önüne alındığında, uzun süredir bilinen bir soruna ilişkin yeni içgörülerin yazılım ortamında herhangi bir ani değişikliği teşvik etme şansı hala zayıf.
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 açısından Güvenli Olmayan Kod İçeriyor
ABD Siber Güvenlik ve Altyapı Güvenlik Ajansı (CISA), bu hafta FBI ve Avustralya Siber Güvenlik Merkezi ile Kanada Siber Güvenlik Merkezi’ndeki muadilleriyle birlikte 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ı.
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.”
Buna ek olarak, uygulamalardaki işlevsel gereksinimleri karşılamak için bellek güvenliği özelliklerini devre dışı bırakma eğilimi ve çoğu zaman duyulan ihtiyaç, genellikle bellek açısından güvenli dillerin kullanılmasını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 Uyumlu
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 aslında, sorunun her yerde bulunmasına ilişkin endişeler, yıllar içinde değişim çağrılarına yol açmıştır. En yenisi bir 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ı Bellek açısından güvenli dilleri benimsemeyi düşünün Modern kod tabanlarındaki bellek yönetimiyle ilgili yazılım sorunlarından kaynaklanan riski azaltmak için. Yıllar boyunca bu konu üzerinde ısrarla durulması, bazı değişiklikleri teşvik ettiAncak çoğu kişi, bellek açısından güvenli dillere tam ölçekli bir geçişin yıllar, hatta on yıllar alacağını öngörü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 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.
“Bugün 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 seviyeli donanım erişimi için genellikle C/C++ gibi bellek açısından güvenli olmayan eski dilleri kullanıyorlar” 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.
“Bellek güvenli olmayan bir dilde bellek güvenli kod yazmak kesinlikle mümkün olsa da, 25 yıllık CVE’ler bunun çok düşük bir ihtimal olduğunu gösteriyor,” diyor Arasaratnam. “İnsanların kötü programcılar olması değil, ancak bellek güvenli olmayan bir dilde bellek güvenli kod yazmak savunmacı bir şekilde çok zordur,” diye belirtiyor. Daha yeni projeler bellek güvenli dilleri benimsedikçe, niş uygulamalar hariç tümünde bellek güvenli olmayan dillerin kullanımının zamanla azalmasını bekleyin.
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?”