Prawie jedna czwarta Androida 13 jest napisana w Rust

Zardzewiały Android 13

Android 13 to pierwsza wersja Androida, w której większość nowego kodu dodanego do wersji jest w języku bezpiecznym dla pamięci.

Poprzez post na blogu, inżynierowie Google opublikował podsumowanie pierwszych wyników wstępu Wsparcie rozwoju Rust na Androida.

Androida 13, skompilowano około 21% nowego kodu Całość jest napisana w języku Rust, a 79% w C/C++, będąc repozytorium AOSP (Android Open Source Project), w którym rozwijany jest kod źródłowy dla platformy Android, który zawiera około 1,5 miliona linii kodu Rust.

Kod dostarczone przez AOSP jest to związane z nowymi komponentami, takimi jak magazyn kluczy kryptograficznych Keystore2, stos dla chipów UWB (Ultra-Wideband), implementacja protokołu DNS przez HTTP3, framework wirtualizacji AVF (Android Virtualization Framework), eksperymentalne stosy dla Bluetooth i Wi-Fi.

W linii z przyjętą powyżej strategią zmniejszania ryzyka wystąpienia podatności na błędy pamięci, Do tej pory Rust był używany głównie do tworzenia nowego kodu i stopniowego wzmacniania bezpieczeństwa najbardziej wrażliwych i kluczowych komponentów oprogramowania.

Wraz ze spadkiem liczby nowych kodów niezabezpieczających pamięć wprowadzanych do Androida, zmniejszyła się również liczba luk w zabezpieczeniach pamięci. Od 2019 do 2022 roku spadł z 76% do 35% wszystkich luk w Androidzie. Rok 2022 to pierwszy rok, w którym luki w zabezpieczeniach pamięci nie stanowią większości luk w zabezpieczeniach Androida.

Ogólny cel przeniesienia całej platformy do Rusta nie jest postawiony, a stary kod pozostaje w C/C++, a walka z błędami w nim odbywa się za pomocą testów fuzzingowych, analizy statycznej i wykorzystania podobnych technik. wykorzystanie typu MiraclePtr (binding over raw pointers, który dodatkowo sprawdza dostęp do zwalnianych obszarów pamięci), systemu alokacji pamięci Scudo (bezpieczny zamiennik dla malloc/free) oraz mechanizmów wykrywania błędów podczas pracy z pamięcią HWAsan (Hardware Assisted AddressSanitizer) , GWP-ASAN i KFENCE.

Jeśli chodzi o statystyki dotyczące charakteru luki w zabezpieczeniach na platformie Android obserwuje się, że as zmniejsza ilość nowego kodu, który działa z pamięcią w niepewny sposób, zmniejsza również liczbę luk spowodowanych błędami podczas pracy z pamięcią.

Na przykład odsetek luk w zabezpieczeniach spowodowanych problemami z pamięcią spadł z 76% w 2019 r. do 35% w 2022 r. W liczbach bezwzględnych w 223 r. zidentyfikowano 2019 luki w zabezpieczeniach pamięci, 150 w 2020 r., 100 w 2021 r. nie znaleziono). Rok 85 był pierwszym rokiem, w którym luki związane z pamięcią przestały dominować.

Jak dotąd nie wykryto żadnych luk w zabezpieczeniach pamięci w kodzie Android Rust.

Nie spodziewamy się, że liczba ta pozostanie zerowa na zawsze, ale biorąc pod uwagę ilość nowego kodu Rust w dwóch wersjach Androida i wrażliwych na bezpieczeństwo komponentów, w których jest używany, jest to znaczący wynik. Pokazuje, że Rust spełnia zamierzony cel, jakim jest zapobieganie najczęstszemu źródłu luk w Androidzie.

Ponieważ luki związane z pamięcią są często najbardziej niebezpieczne, ogólne statystyki pokazują również spadek liczby problemów krytycznych i problemów, które można wykorzystać zdalnie. Jednocześnie dynamika wykrywania podatności niezwiązanych z pracą z pamięcią od 4 lat utrzymuje się mniej więcej na tym samym poziomie - 20 podatności miesięcznie.

Stosunek niebezpiecznych problemów do podatności spowodowanych błędami pamięci jest również taki sam (ale wraz ze spadkiem liczby podatności maleje również liczba niebezpiecznych problemów).

Statystyki śledzą również korelację między ilością nowego kodu, który działa z pamięcią w sposób niepewny, a liczbą luk związanych z pamięcią (przepełnienie bufora, dostęp do już zwolnionej pamięci itp.).

Ta obserwacja potwierdzić założenie że główną uwagę w wdrażanie bezpiecznych technik programowania należy go dać nowemu kodowi, a nie przepisywać istniejący, ponieważ większość zidentyfikowanych luk znajduje się w nowym kodzie.

źródło: https://security.googleblog.com/


Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: AB Internet Networks 2008 SL
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.