Google, güvenli tasarım yaklaşımının bir parçası olarak Rust gibi bellek açısından güvenli dillere geçişinin, Android’de keşfedilen bellek açısından güvenli güvenlik açıklarının oranının altı yıllık bir süre içinde %76’dan %24’e düşmesine yol açtığını açıkladı.
Teknoloji devi, odaklanmanın Güvenli Kodlama Yeni özellikler yalnızca bir kod tabanının genel güvenlik riskini azaltmakla kalmaz, aynı zamanda geçişi daha “ölçeklenebilir ve uygun maliyetli” hale getirir.
Google’dan Jeff Vander Stoep ve Alex Rebert, bunun sonucunda belirli bir süre sonra yeni güvenli olmayan bellek geliştirmenin yavaşlaması ve yeni güvenli bellek geliştirmenin devralmasıyla bellek güvenliği açıklarında bir düşüş yaşandığını söylüyor. söz konusu The Hacker News ile paylaşılan bir gönderide.
Belki daha da ilginci, yeni bellek güvenliği olmayan kod miktarındaki artışa rağmen bellek güvenliği açıklarının sayısı da düşebilir.
Bu paradoks, güvenlik açıklarının üstel olarak azalması gerçeğiyle açıklanıyor; yapılan bir araştırma, çok sayıda güvenlik açığının çoğunlukla yeni veya yakın zamanda değiştirilmiş kodlarda bulunduğunu ortaya koyuyor.
“Sorun ezici bir şekilde yeni koddadır ve bu da kodu geliştirme şeklimizde temel bir değişiklik gerektirir,” diye belirtti Vander Stoep ve Rebert. “Kod zamanla olgunlaşır ve daha güvenli hale gelir, katlanarak, kod eskidikçe yeniden yazma gibi yatırımların getirileri zamanla azalır.”
Nisan 2021’de Android’de Rust programlama dilini destekleme planlarını resmen duyuran Google, 2019 yılı civarında yeni geliştirmeleri bellek açısından güvenli dillere geçirmeye öncelik vermeye başladığını söyledi.
Sonuç olarak, işletim sisteminde keşfedilen bellek güvenliği açıklarının sayısı azaldı 2019’da 223 2024 yılında 50’nin altına düşecek.
Ayrıca, bu tür kusurlardaki azalmanın büyük bir kısmının, bunlarla mücadele etmek için geliştirilen yöntemlerdeki gelişmelerden kaynaklandığını söylemeye gerek yok; Clang temizleyicileri gibi araçları kullanarak reaktif yamalar uygulamaktan proaktif azaltmaya ve proaktif güvenlik açığı keşfine geçiliyor.
Teknoloji devi ayrıca, bellek güvenliği stratejilerinin “yüksek güvenceli önleme”yi önceliklendirerek daha da gelişmesi gerektiğini belirtti. tasarıma göre güvenli ilkeler güvenliği temellerine yerleştiren.
Vander Stoep ve Rebert, “Uygulanan müdahalelere (azaltma, bulanıklaştırma) odaklanmak veya gelecekteki güvenliği tahmin etmek için geçmiş performansı kullanmaya çalışmak yerine, Güvenli Kodlama, kodun özellikleri ve bu özelliklere dayanarak neyin olabileceği veya olamayacağı hakkında güçlü iddialarda bulunmamızı sağlıyor” dedi.
Hepsi bu kadar değil. Google ayrıca, bellek güvenli dilleri benimsemek ve nihayetinde tüm güvenlik açığı sınıflarını ortadan kaldırmak için “pratik ve artımlı bir yaklaşım” olarak kod yeniden yazma yerine Rust, C++ ve Kotlin arasında birlikte çalışabilirlik sunmaya odaklandığını söyledi.
“Yeni kodda Güvenli Kodlamayı benimsemek, paradigma değişimini sunarak, büyük mevcut sistemlerde bile, güvenlik açıklarının içsel azalmasını kendi avantajımıza kullanmamıza olanak tanır,” denildi.
“Konsept basit: Yeni güvenlik açıklarının musluğunu kapattığımızda, bunlar katlanarak azalır, tüm kodlarımız daha güvenli hale gelir, güvenlik tasarımının etkinliği artar ve mevcut bellek güvenliği stratejileriyle ilişkili ölçeklenebilirlik zorlukları hafifletilir, böylece bunlar hedefli bir şekilde daha etkili bir şekilde uygulanabilir.”
Gelişme, Google’ın Android ekosistemindeki GPU yazılım/donanım yığınının genel güvenliğini artırmak ve çok sayıda eksikliği tespit etmek için Arm’ın ürün güvenliği ve grafik işleme birimi (GPU) mühendislik ekipleriyle işbirliğini artırmayı duyurmasının ardından geldi.
Bu, Pixel’in sürücü kodunun özelleştirilmesinde iki bellek sorununun keşfedilmesini içerir (CVE-2023-48409 ve CVE-2023-48421) ve Arm Valhall GPU aygıt yazılımında ve 5. Nesil GPU mimarisi aygıt yazılımında bir diğeri (CVE-2024-0153).
“Proaktif test, yeni güvenlik açıklarının istismar edilmeden önce tespit edilip çözülmesine yol açabileceğinden iyi bir hijyendir” diyor Google ve Armor söz konusu.
