Android yavaş yavaş bellek yönetimi güvenlik açıklarında uzmanlaşıyor

Geçenlerde NSA’nın neden bellek açısından güvenli programlama dillerine geçmenizi istediğini yazdık. Kısa versiyonu: Güvenlik açıklarını açıklayan yazılarımızı okursanız, bir pay “arabellek taşması”, “bellek serbest bırakılamadı”, “boş olduktan sonra kullan”, “bellek bozulması” ve “bellek sızıntısı” gibi tümcecikler. Bunların hepsi bellek yönetimi sorunlarıdır. Bellek yönetimi sorunlarını önlemenin en iyi yolu, bir programcının her şeyi doğru şekilde kodlamasına güvenmek yerine belleği otomatik olarak yöneten, bellek açısından güvenli bir dil kullanmaktır.

NSA’nın peşine düşen Google, güvenlik blogunda ajansın bakış açısını desteklemek için bazı rakamlar sağlayan bir makale yayınladı. Google, güvenli bellek programlama dillerinin kullanımı arttıkça Android işletim sistemindeki bellek güvenlik açıklarında önemli bir düşüş gördüğünü bildiriyor.

Sayılar

Her zaman istatistik konusunda titiz olmuşumdur, ancak size ne söylediklerini anlamadan önce her kategorinin kaynağını, popülasyonunu ve sınırlarını göz önünde bulundurmalısınız. Yayıncı, sunulan verilere dayanmayan sözde bilimsel iddialar kullanarak sizi bir sonuca varmanız için manipüle etmeye çalışmıyorsa, istatistikler, neden ve sonuç arasındaki ilişkiyi göstermenize olanak tanır.

Etki

Google güvenlik ekibi, güvenlik açığı ödül programı aracılığıyla bildirilen kritik/yüksek önem dereceli güvenlik açıklarını ve dahili olarak bildirilen güvenlik açıklarını içeren Android güvenlik bülteninde bildirilen güvenlik açıklarını inceledi. Bellek güvenlik açıklarının sayısının 2019’dan bu yana her yıl bir önceki yıla göre düşüş gösterdiğini fark etti. 2019’da 223, 2022’de 85 idi.

Neden

Bellek güvenlik açıklarındaki bu düşüş, programlama dillerindeki bir değişimle çakışıyor. Android işletim sisteminin geliştirilmesinde Kotlin, Java, Rust gibi hafıza güvenliği olmayan dillerin kullanılmaya başlanmasıyla birlikte C ve C++ ile kodlanan, arka planda her şeyi birbirine bağlayan yazılıma olan katkılar oldukça azaldı.

Diğer olası nedenler

Dolayısıyla, belleğe güvenli dillerde yazma ile bildirilen bellekle ilgili güvenlik açıklarının sayısı arasında net bir ilişki görebiliriz. Ancak korelasyon her zaman gerçek bir nedensellik olduğu anlamına gelmez. Oyunda başka faktörler olabilir.

Yazılım hataları zamanla bulunur ve düzeltilir, bu nedenle, korunan ancak aktif olarak geliştirilmeyen olgun koddaki hataların sayısının zaman içinde düşmesini bekleyebiliriz.

Korelasyonun nedeninin bu olmadığını göstermek için Google ekibi, daha önce C++’ta uygulanacak ancak Rust’ta kodlanmış bir sistem dili gerektiren yeni düşük seviyeli bileşenlere baktı. Sonuç etkileyiciydi:

Bugüne kadar, Android’in Rust kodunda sıfır bellek güvenlik açığı keşfedildi.

Yeni işlevler genelinde Android Açık Kaynak Projesi’nde (AOSP) yaklaşık 1,5 milyon satır Rust kodu vardır. Google’a göre, tarihsel olarak güvenlik açığı yoğunluğu, bin kod satırı başına birden fazla güvenlik açığıdır. Rust bu örneği izlemiş olsaydı, binlerce olmasa da yüzlerce güvenlik açığı oluşturacaktı.

Yan etkiler

Google ekibi, nedenselliği bir kez daha kontrol etmek için bellekle ilgili olmayan güvenlik açıklarını da inceledi. Bellek güvenlik açıklarının sayısı önemli ölçüde azalmış olsa da, güvenlik açıklarının toplam sayısı son dört yılda bir şekilde sabit kalarak ayda yaklaşık 20’ye ulaştı.

Bellekle ilgili hatalar ve diğerleri arasındaki önem farkı nedeniyle, bulunan güvenlik açıklarının genel önem derecesi ve bellek güvenlik açıklarının sayısı azaldı. Bellek güvenlik açıkları, yaratabilecekleri etki nedeniyle genellikle bir saldırgan için çok daha değerlidir. Bir işlemdeki kod yürütme güvenlik açığından yararlanmak, yalnızca belirli bir kaynağa değil, diğer işlemlere yönelik saldırı yüzeyi de dahil olmak üzere bu işlemin erişebildiği her şeye erişim sağlar.

Bazı görevler, manuel bellek yönetimi gerektirir veya bununla daha iyi çalışır; bu nedenle, artan risk karşılığında programcıya daha fazla özgürlük sağlayan bellek açısından güvenli olmayan sınıflar veya işlevler mevcuttur. Uygulamada bu, bellek açısından güvenli dillerin bir kaçış kapağına ihtiyaç duyduğu anlamına gelir. Örneğin pas, unsafe{} sistem kaynakları ve Rust olmayan kodla etkileşime izin veren kaçış kapağı.

Bu “güvenli olmayan” çıkışların kullanıldığı durumlarda Google, güvenlik açıklarına yol açabilecek durumları ortadan kaldırmak için koda ekstra özen gösterir.

Güvenli olmayan kodla ilgili güvenliği artırmak, genellikle ek korumalı alan, temizleyiciler, çalışma zamanı azaltmaları ve donanım korumaları gibi daha fazla kod eklemek anlamına gelir. Bunların tümü kod boyutunu, belleği ve performansı olumsuz etkiler.

Devam edecek

C/C++’dan geçiş yapmak zordur, ancak Android geliştiricileri ilerleme kaydediyor. Amaç, Rust’ı kod tabanında yerel kodun gerekli olduğu herhangi bir yerde kullanmaktır. Ve Linux 6.1’de Rust iniş desteği ile Google, çekirdek sürücülerinden başlayarak çekirdeğe bellek güvenliği getirmeyi beklediğini söylüyor.

---

Tehditleri sadece rapor etmiyoruz, onları kaldırıyoruz

Siber güvenlik riskleri asla bir manşetin ötesine geçmemelidir. Malwarebytes’i bugün indirerek tehditleri cihazlarınızdan uzak tutun.