Niebezpieczeństwo związane z pamięcią
Najczęstszym problemem w kodzie źródłowym Androida są błędy związane z zabezpieczeniami pamięci, czyli błędy w obsługiwaniu pamięci w natywności. Stanowią one ponad 60% luk w zabezpieczeniach o wysokiej wadze i spowodowały miliony widocznych dla użytkowników awarii.
Błędy związane z bezpieczeństwem pamięci mają negatywny wpływ na jakość i stabilność oraz odpowiadają za znaczną część awarii na urządzeniach użytkowników końcowych. Dlatego duża gęstość błędów związanych z bezpieczeństwem pamięci jest bezpośrednio związana z niekorzystnymi wrażeniami użytkownika.
Kod natywny napisany w językach nieobsługujących pamięci, takich jak C, C++ i Assembly, stanowi ponad 70% kodu na platformę Androida i występuje w przypadku około 50% aplikacji ze Sklepu Google Play.
Biorąc pod uwagę stale rosnącą złożoność kodu, jeśli nie będzie on monitorowany, z czasem będzie się zwiększać liczba błędów związanych z bezpieczeństwem pamięci. Dlatego udostępnianie naszej platformie narzędzi i technologii, które wykrywają takie błędy i ograniczają ich wpływ, jest kluczowe dla naszego długoterminowego sukcesu.
Przez ostatnie kilka lat ściśle współpracowaliśmy z partnerami w zakresie sprzętu, aby opracowywać technologie sprzętowe, takie jak tagowanie pamięci Arm. Wprowadziliśmy też Rust w kodzie źródłowym Androida.
Te technologie przyspieszą nasz rozwój w kierunku bezpieczeństwa pamięci i pomogą całej branży oprogramowania rozwiązać kluczowy problem.
Błędy związane z bezpieczeństwem pamięci negatywnie wpływają na jakość
Ukryte błędy dotyczące bezpieczeństwa pamięci mogą powodować niedeterministyczne wyniki, w zależności od stanu systemu. To nieprzewidywalne zachowanie prowadzi do awarii i frustracji użytkowników.
Każdego dnia obserwujemy miliony przypadków awarii natywnych aplikacji na urządzeniach użytkowników. Po wprowadzeniu GWP-ASan większość z nich udało nam się przypisać do błędów związanych z bezpieczeństwem pamięci.
Te dane potwierdzają korelację między jakością a gęstością błędów związanych z bezpieczeństwem pamięci i zgadzają się z obserwacjami naszych współpracowników z zespołu Chromium (patrz lista gorących błędów GWP-ASAN w Chrome).
Błędy związane z bezpieczeństwem pamięci negatywnie wpływają na bezpieczeństwo
Błędy związane z bezpieczeństwem pamięci były od samego początku Androida głównym źródłem luk w zabezpieczeniach tego systemu.
Chociaż cieszy nas, że to nie jest problem tylko Androida (patrz statystyki Chrome i Microsoft), musimy zrobić więcej, aby zapewnić bezpieczeństwo naszym użytkownikom.
Zespół Project Zero w Google śledzi
luki zero-day, które były wykorzystywane w rzeczywistych atakach na użytkowników, jako luki zero-day. To nie są hipotetyczne błędy, ale luki w zabezpieczeniach, które są aktywnie wykorzystywane w atakach na użytkowników. Większość z nich to błędy związane z bezpieczeństwem pamięci (uszkodzenie pamięci i błędy use-after-free).
Błędy związane z bezpieczeństwem pamięci zwiększają koszty
Aktualizowanie urządzeń z poprawkami bezpieczeństwa zapewnia bezpieczeństwo użytkownikom, ale wiąże się z kosztami dla naszego ekosystemu.
Wysoka gęstość błędów związanych z bezpieczeństwem pamięci w niskopoziomowym kodzie dostawcy, który często zawiera niestandardowe modyfikacje, znacznie zwiększa koszty naprawy i testów. Jednak wykrycie tych błędów we wczesnym etapie cyklu programowania może obniżyć te koszty.
Badania pokazują, że wcześniejsze wykrywanie błędów może zmniejszyć koszty nawet 6-krotnie. Jednak ze względu na złożoność naszego ekosystemu, średnią liczbę baz kodu obsługiwanych przez dostawcę i stale rosnącą złożoność oprogramowania oszczędności mogą być większe.
Bezpieczeństwo pamięci
Od Androida 12 wprowadziliśmy zmiany systemowe, aby zmniejszyć gęstość błędów związanych z bezpieczeństwem pamięci w kodach źródłowych Androida. Rozszerzamy narzędzia do ochrony pamięci na Androidzie i wprowadzamy nowe wymagania, które zachęcą ekosystem do rozwiązywania problemów z tej kategorii. Z czasem powinno to przełożyć się na wyższą jakość i lepsze bezpieczeństwo dla użytkowników oraz niższe koszty dla dostawców.
W najbliższych latach bezpieczeństwo pamięci może stać się czynnikiem wyróżniającym pod względem jakości i bezpieczeństwa, a Android zamierza wyznaczać w tej kwestii trendy.
Wymagania dotyczące bezpieczeństwa pamięci
Dokument definicji zgodności Androida (CDD) zdecydowanie zaleca korzystanie z narzędzi do ochrony pamięci podczas tworzenia aplikacji.
Współpracujemy z naszym ekosystemem, aby zwiększyć wykorzystanie narzędzi do ochrony pamięci i zintegrować je z procesami ciągłej integracji i testowania.
Z czasem chcemy mieć pewność, że każde urządzenie przechodzi pełny test Compatibility Test Suite (CTS) za pomocą narzędzi do ochrony pamięci, co oznacza, że nie znaleziono żadnych takich błędów. Na przykład platformy Arm w wersji 9 będą musiały przeprowadzić test CTS z włączonym oznaczeniem pamięci, a platformy Arm w wersji 8 będą musiały przeprowadzić test CTS z wykorzystaniem HWASAN i KASAN.
Rust jako nowy język programowania kodu platformy
Android 12 wprowadził Rust jako język platformy. Rust zapewnia bezpieczeństwo pamięci i wątek na poziomie wydajności podobnym do C/C++. Spodziewamy się, że Rust będzie preferowanym językiem w przypadku większości nowych projektów natywnych. Jednak przepisanie w języku Rust całego kodu, który obecnie stanowi ponad 70% kodu platformy Androida, jest niemożliwe. W przyszłości Rust będzie uzupełnieniem narzędzi do ochrony pamięci.
Narzędzia dotyczące bezpieczeństwa pamięci
Android obsługuje wiele narzędzi, które pomagają wykrywać błędy związane z bezpieczeństwem pamięci. Rysunek poniżej przedstawia taksonomię dostępnych narzędzi do ochrony pamięci na Androidzie.
Nasze narzędzia obsługują wiele scenariuszy wdrożenia i celów. W tej dokumentacji opisaliśmy poszczególne narzędzia i zamieściliśmy informacje o ich używaniu w Twoich usługach.