Android 13'ün neredeyse dörtte biri Rust'ta yazılıyor

Rust android 13

Android 13, sürüme eklenen yeni kodun çoğunun bellek açısından güvenli bir dilde olduğu Android'in ilk sürümüdür.

Bir blog gönderisi aracılığıyla, Google mühendisleri ilk sonuçların özetini yayınladı girişin Android'de Rust geliştirme desteği.

Android 13, derlenen yeni kodun yaklaşık %21'i Toplam, yaklaşık 79 milyon satır Rust kodu içeren Android platformu için kaynak kodunu geliştiren AOSP (Android Açık Kaynak Projesi) deposu olan Rust'ta ve %1,5'u C/C++'da yazılmıştır.

Kod AOSP tarafından sağlanan Keystore2 kriptografik anahtar deposu, UWB (Ultra Geniş Bant) yongaları için yığın, HTTP3 üzerinden DNS protokolünün uygulanması, AVF sanallaştırma çerçevesi (Android Sanallaştırma Çerçevesi), Bluetooth ve Wi-Fi için deneysel yığınlar gibi yeni bileşenlerle ilgilidir.

Sıralı bellek hatası güvenlik açıkları riskini azaltmak için yukarıda benimsenen strateji ile, Şimdiye kadar Rust, esas olarak yeni kod geliştirmek ve en savunmasız ve hayati yazılım bileşenlerinin güvenliğini kademeli olarak güçlendirmek için kullanıldı.

Android'e giren yeni bellek güvenli olmayan kod sayısı azaldıkça, bellek güvenlik açıklarının sayısı da azalmıştır. 2019'dan 2022'ye, toplam Android güvenlik açıklarının %76'sından %35'ine düştü. 2022, bellek güvenlik açıklarının Android güvenlik açıklarının çoğundan sorumlu olmadığı ilk yılı işaret ediyor.

Tüm platformun Rust'a aktarılması genel amacı belirlenmemiş olup, eski kod C/C++'da kalmakta ve içindeki bug'larla mücadele fuzzing testleri, statik analiz ve benzeri teknikler kullanılarak yapılmaktadır. HWAsan (Donanım Destekli AdresSanitizer) bellek ile çalışırken MiraclePtr türünün kullanımı (boş bellek alanlarına erişim için ek kontroller gerçekleştiren ham işaretçiler üzerinden bağlama), Scudo bellek ayırma sistemi (malloc/free için güvenli bir yedek) ve hata algılama mekanizmaları , GWP-ASAN ve KFENCE.

doğasına ilişkin istatistiklerle ilgili olarak güvenlik açıkları Android platformunda, şu şekilde görülmektedir: bellekle güvenli olmayan şekillerde çalışan yeni kod miktarını azaltır, bellekle çalışırken hatalardan kaynaklanan güvenlik açıklarının sayısını da azaltır.

Örneğin, bellek sorunlarının neden olduğu güvenlik açıklarının oranı 76'da %2019'dan 35'de %2022'e düştü. Mutlak rakamlarla, 223'da 2019, 150'de 2020, 100'de 2021 ve 85'de 2022 bellekle ilgili güvenlik açığı belirlendi. bulunamadı). 2022, bellekle ilgili güvenlik açıklarının hakimiyetinin sona erdiği ilk yıl oldu.

Bugüne kadar, Android Rust kodunda herhangi bir bellek güvenlik açığı keşfedilmemiştir.

Bu sayının sonsuza kadar sıfırda kalmasını beklemiyoruz, ancak Android'in iki sürümündeki yeni Rust kodunun hacmi ve kullanıldığı güvenlik açısından hassas bileşenler göz önüne alındığında, bu önemli bir sonuç. Rust'ın en yaygın Android güvenlik açıkları kaynağını önleme amacına hizmet ettiğini gösterir.

Dado que bellekle ilgili güvenlik açıkları genellikle en tehlikeli olanlardır, genel istatistikler ayrıca kritik sorunların ve uzaktan yararlanılabilecek sorunların sayısında bir azalma olduğunu gösteriyor. Aynı zamanda, bellekle çalışmayla ilgili olmayan güvenlik açıklarını tespit etme dinamikleri, son 4 yıldır yaklaşık olarak aynı seviyede - ayda 20 güvenlik açığı.

Tehlikeli sorunların bellek hatalarından kaynaklanan güvenlik açıklarına oranı da aynıdır (ancak güvenlik açıklarının sayısı azaldıkça tehlikeli sorunların sayısı da azalır).

İstatistikler ayrıca bellekle güvenli olmayan bir şekilde çalışan yeni kod miktarı ile bellekle ilgili güvenlik açıklarının sayısı (arabellek taşmaları, önceden boşaltılmış belleğe erişim vb.) arasındaki ilişkiyi de izler.

Bu gözlem varsayımını doğrulamak ana dikkatin güvenli programlama tekniklerinin uygulanması tespit edilen güvenlik açıklarının çoğu yeni kodda olduğu için yeni koda verilmeli ve var olan kod tekrar yazılmamalıdır.

kaynak: https://security.googleblog.com/


Yorumunuzu bırakın

E-posta hesabınız yayınlanmayacak. Gerekli alanlar ile işaretlenmiştir *

*

*

  1. Verilerden sorumlu: AB Internet Networks 2008 SL
  2. Verilerin amacı: Kontrol SPAM, yorum yönetimi.
  3. Meşruiyet: Onayınız
  4. Verilerin iletilmesi: Veriler, yasal zorunluluk dışında üçüncü kişilere iletilmeyecektir.
  5. Veri depolama: Occentus Networks (AB) tarafından barındırılan veritabanı
  6. Haklar: Bilgilerinizi istediğiniz zaman sınırlayabilir, kurtarabilir ve silebilirsiniz.