Android’deki bellekle ilgili güvenlik açıklarının sayısı, Google’ın çoğu yeni kod için Rust gibi bellek açısından güvenli dillerin kullanımını vurgulayan tasarım gereği güvenli bir yaklaşım kullanması sayesinde son beş yılda keskin bir düşüş gösterdi.
Arabellek taşmaları ve serbest kullanım hataları gibi bellek güvenliği sorunları, 2019’daki %76 oranına kıyasla artık tüm Android güvenlik açıklarının yalnızca %24’ünü oluşturuyor. Bu yıl şu ana kadarki rakamlar, 2024 yılının tamamı için Android belleğiyle ilgili toplam 36 güvenlik açığı olduğunu gösteriyor veya geçen seneki sayının kabaca yarısı kadar ve 2019’daki 223 kusurdan çok uzak.
Tasarım Yoluyla Güvenli Yaklaşımı Sonuç Verir
bir 25 Eylül blog yazısıGoogle’ın Android ve güvenlik ekiplerinden araştırmacılar, ilerlemeyi, yeni kod geliştirme için Rust gibi bellek açısından güvenli dillere öncelik veren, şirketteki tasarım gereği güvenli bir yaklaşım olan Güvenli Kodlama’ya bağladı. Araştırmacılar, “Öğrendiklerimize dayanarak, hafıza açısından güvenli olmayan mevcut tüm kodlarımızı atmamıza veya yeniden yazmamıza gerek olmadığı açıkça ortaya çıktı” diye yazdı. “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.”
Bellek güvenliği açıkları Geleneksel olarak tüm uygulama yazılımı güvenlik açıklarının %60’ından fazlasının sorumlusu olmuştur ve olmaya da devam etmektedir. Ayrıca diğer kusurlarla karşılaştırıldığında orantısız derecede şiddetlidirler. Örneğin 2022’de hafızayla ilgili hatalar Tanımlanan tüm Android güvenlik açıklarının yalnızca %36’sını oluşturuyor ancak işletim sistemindeki en ciddi kusurların %86’sını ve onaylanmış Android hatalarının %78’ini oluşturuyordu.
Bunun büyük bir kısmı, C ve C++ gibi yaygın olarak kullanılan programlama dillerinin, yazılım geliştiricilerin belleği doğrudan yönetmesine olanak tanıması ve hataların içeri sızması için kapıyı açık bırakmasıyla ilgilidir. Bunun aksine, Rust, Go ve C# gibi bellek açısından güvenli diller özelliği otomatik bellek yönetimi ve bellekle ilgili yaygın hatalara karşı yerleşik güvenlik kontrolleri. ABD dahil çok sayıda güvenlik paydaşı Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA) ve hatta Beyaz Saray bellek açısından güvenli olmayan dillerin kullanılmasıyla ilişkili artan güvenlik açıkları ve bunları ele almanın önemli maliyetleriyle ilgili endişeleri artırdı. Bellek açısından güvenli dillere geçiş yapılırken yavaş yavaş ivme kazanıyorçoğu kişi mevcut kod tabanlarını tamamen bellek açısından güvenli koda taşımanın yıllar ve muhtemelen on yıllar alacağını düşünüyor.
Kademeli Geçiş
Google’ın soruna yaklaşımı, yeni Android özellikleri için Rust gibi hafıza açısından güvenli diller kullanmak ve hata düzeltmeleri dışında mevcut kodu büyük ölçüde değiştirmemek oldu. Sonuç olarak, iki Google araştırmacısı, son birkaç yılda, hafıza açısından güvenli olmayan dilleri içeren yeni geliştirme faaliyetlerinde kademeli bir yavaşlamanın, hafıza açısından güvenli olmayan geliştirme faaliyetlerindeki artışla eşleştiğini söyledi.
Google, geçişe Android 12’deki Rust desteğiyle başladı ve Android Açık Kaynak Projesi kapsamında programlama dilinin kullanımını giderek artırıyor. Android 13, işletim sistemindeki yeni kodun çoğunun hafıza açısından güvenli bir dilde olduğu ilk kez oldu. O dönemde Google, amacının tüm C ve C++ kodlarını Rust’a dönüştürmek değil, zaman içinde kademeli olarak yeni programlama diline geçiş yapmak olduğunu vurgulamıştı.
Bu yılın başlarında yayınlanan bir blog yazısında, Google’ın güvenlik mühendisliği ekibinin üyeleri şunları gördüklerini belirtti: “C++’ın evrimi için gerçekçi bir yol yok Ancak Google, bundan bir anda uzaklaşmak yerine, şirketin bu dillerde yazılmış mevcut kod tabanlarını desteklemek için C ve C++’da bellek güvenliğini artıracak araçlara yatırım yapmaya devam edecek.
Google, önemli bir şekilde, bellekle ilgili hataların tüm Android güvenlik açıkları içindeki yüzdesi olarak, yalnızca şirketin Rust gibi bellek açısından güvenli bir dili giderek daha fazla kullanması nedeniyle değil, aynı zamanda eski güvenlik açıklarının zamanla azalması nedeniyle de azaldığını buldu. Araştırmacılar, belirli bir kod miktarındaki (genellikle güvenlik açığı yoğunluğu olarak adlandırılan) güvenlik açıklarının sayısının, beş yıllık Android kodunda yeni kodla karşılaştırıldığında daha düşük olduğunu buldu.
Araştırmacılar, “Sorun büyük ölçüde yeni koddan kaynaklanıyor ve kod geliştirme şeklimizde temel bir değişiklik gerektiriyor” dedi.