Android’de bellek güvenliği sorunlarından kaynaklanan güvenlik açıklarının oranı 2019’da %76 iken 2024’te sadece %24’e düştü. Bu, beş yılda %68’den fazla büyük bir düşüşü temsil ediyor.
Bu oran, Chromium’da daha önce bulunan %70’in oldukça altında kalarak Android’i, büyük bir projenin geriye dönük uyumluluğu bozmadan kademeli ve metodik bir şekilde güvenli bir bölgeye nasıl geçebileceğinin mükemmel bir örneği haline getiriyor.
Google, bu sonuca, Rust gibi bellek açısından güvenli dillerde yazılan yeni kodlara öncelik vererek ulaştığını ve böylece zamanla yeni hataların ortaya çıkmasını en aza indirdiğini söylüyor.
Aynı zamanda eski kod, kapsamlı yeniden yazmalar yapmak yerine, önemli güvenlik düzeltmelerine odaklanan minimal değişikliklerle korundu; bu da birlikte çalışabilirliği zayıflatacaktı.
Google’ın raporunda, “Öğrendiklerimize dayanarak, mevcut bellek açısından güvenli olmayan kodlarımızın tamamını atmamıza veya yeniden yazmamıza gerek olmadığı açıkça ortaya çıktı.” ifadeleri yer alıyor.
“Bunun yerine Android, bellek güvenliği yolculuğumuzda birincil yetenek olarak birlikte çalışabilirliği güvenli ve kullanışlı hale getirmeye odaklanıyor.”
Bu strateji, eski kodun zamanla olgunlaşmasını ve daha güvenli hale gelmesini sağlayarak, hangi dilde yazılmış olursa olsun içindeki bellekle ilgili güvenlik açıklarının sayısını azaltır.
Android’in inşa stratejisindeki bu iki temel unsur, dünyanın en yaygın kullanılan mobil platformunda bellek kusurlarının önemli ölçüde azaltılması yönünde sinerjik bir etki yarattı.
Google, eski kodu temelde değiştirmeden bırakmanın riskli görünebileceğini ve yeni kodun daha iyi test edilip incelenmesinin beklendiğini, ancak bunun ne kadar mantıksız görünse de tam tersinin gerçekleştiğini açıklıyor.
Bunun nedeni, son kod değişikliklerinin çoğu hatayı beraberinde getirmesidir, bu nedenle yeni kod neredeyse her zaman güvenlik sorunları içerir. Aynı zamanda, geliştiriciler kapsamlı değişiklikler yapmadığı sürece eski koddaki hatalar giderilir.
Google, sektörün ve kendisinin bellek güvenliği açıklarıyla başa çıkmada dört ana aşamadan geçtiğini, bunların aşağıda özetlendiğini söylüyor:
- Reaktif yama: Başlangıçta, odak noktası, keşfedildikten sonra güvenlik açıklarını gidermekti. Bu yaklaşım, sürekli maliyetlere, sık güncellemelere ve kullanıcıların bu arada savunmasız kalmasına neden oldu.
- Proaktif azaltmalar: Bir sonraki adım, istismarları daha zor hale getirmek için stratejiler uygulamak oldu (örneğin, yığın kanaryaları, kontrol akışı bütünlüğü). Ancak, bu önlemler genellikle performans tavizleriyle geldi ve saldırganlarla kedi-fare oyununa yol açtı.
- Proaktif güvenlik açığı keşfi: Bu nesil, güvenlik açıklarını proaktif bir şekilde bulmak için bulanıklaştırma ve dezenfektanlar gibi araçların kullanılmasını içeriyordu. Yardımcı olsa da, bu yöntem yalnızca semptomları ele alıyordu ve sürekli dikkat ve çaba gerektiriyordu.
- Yüksek güvenceli önleme (Güvenli Kodlama): En son yaklaşım, Rust gibi bellek güvenli dilleri kullanarak güvenlik açıklarını kaynağında önlemeye vurgu yapıyor. Bu “tasarıma göre güvenli” yöntem, ölçeklenebilir ve uzun vadeli güvence sağlayarak reaktif düzeltmeler ve maliyetli azaltmalar döngüsünü kırıyor.
Google, “Sektör genelindeki ürünler bu yaklaşımlarla önemli ölçüde güçlendi ve güvenlik açıklarına yanıt verme, bunları azaltma ve proaktif bir şekilde arama konusunda kararlıyız” şeklinde açıklama yaptı.
“Bununla birlikte, bu yaklaşımların bellek güvenliği alanında kabul edilebilir bir risk düzeyine ulaşmak için yetersiz olduğu ve geliştiriciler, kullanıcılar, işletmeler ve ürünler için sürekli ve artan maliyetlere yol açtığı giderek daha da netleşiyor.
“CISA da dahil olmak üzere çok sayıda devlet kurumunun güvenli tasarım raporunda vurgulandığı gibi, “yalnızca güvenli tasarım uygulamalarını dahil ederek, sürekli olarak düzeltmeler oluşturma ve uygulama kısır döngüsünü kırabiliriz.”
ABD Siber Güvenlik ve Altyapı Güvenlik Ajansı (CISA), geçen haziran ayında en yaygın kullanılan açık kaynaklı projelerin %52’sinin bellek açısından güvenli olmayan diller kullandığı konusunda uyarıda bulunmuştu.
Bellek açısından güvenli dillerde yazılmış projeler bile çoğu zaman bellek açısından güvenli olmayan dillerde yazılmış bileşenlere bağımlıdır, bu nedenle güvenlik riskini ele almak karmaşıktır.
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 kritik bileşenleri bu dillere taşımalarını önerdi.