Brak bezpieczeństwa pamięci
Najczęstszym problemem w kodzie źródłowym Androida są błędy związane z bezpieczeństwem pamięci, czyli błędy w obsługiwaniu pamięci w natywności. Stanowią ponad 60% luk w zabezpieczeniach o wysokiej wadze i milionów awarii widocznych dla użytkowników.
Błędy związane z bezpieczeństwem pamięci negatywnie wpływają na jakość i stabilność, a także stanowią znaczną część awarii zaobserwowanych na urządzeniach użytkowników. Dlatego duża gęstość błędów związanych z bezpieczeństwem pamięci jest bezpośrednio powiązana z niekorzystnymi wrażeniami użytkownika.
Kod natywny napisany w niebezpiecznych językach, takich jak C, C++ czy Assembly, stanowi ponad 70% kodu platformy Androida i znajduje się w około 50% aplikacji w Sklepie 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 naszemu ekosystemowi narzędzi i technologii, które mogą wykrywać takie błędy i je ograniczać, jest kluczowe dla naszego długoterminowego sukcesu.
Przez ostatnie kilka lat ściśle współpracowaliśmy z partnerami sprzętowymi nad rozwojem technologii sprzętowych, takich 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 dotyczące bezpieczeństwa pamięci negatywnie wpływają na jakość
Ukryte błędy związane z zabezpieczeniami pamięci mogą powodować niedeterministyczne wyniki, w zależności od stanu systemu. To nieprzewidywalne zachowanie prowadzi do awarii i irytacji 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 początku istnienia Androida głównym źródłem luk w zabezpieczeniach tego systemu.
Chociaż cieszy nas, że nie jest to 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 typu zero-day, które były wykorzystywane w prawdziwych atakach na użytkowników jako luki w zabezpieczeniach typu zero-day. To nie są hipotetyczne błędy, ale luki w zabezpieczeniach, które są aktywnie wykorzystywane w atakach na użytkowników. Zdecydowaną większość błędów stanowią błędy związane z bezpieczeństwem pamięci (uszkodzenie pamięci i wykorzystanie po uwolnieniu).
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
Począwszy od Androida 12 wprowadziliśmy zmiany systemowe, które mają zmniejszyć gęstość błędów związanych z bezpieczeństwem pamięci w bazach kodu Androida. Rozszerzamy zakres narzędzi do zapewniania bezpieczeństwa pamięci Androida i wprowadzamy nowe wymagania, które zachęcają nasz ekosystem do naprawiania tej kategorii błędów. 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 planuje wyznaczać kierunek rozwoju w tej dziedzinie.
Wymagania dotyczące bezpieczeństwa pamięci
Dokument definicji zgodności Androida (CDD) zdecydowanie zaleca używanie narzędzi do ochrony pamięci podczas tworzenia aplikacji.
Ściśle współpracujemy z naszym ekosystemem, aby zwiększać wykorzystanie narzędzi do zapewniania bezpieczeństwa pamięci oraz integrować je w procesach ciągłej integracji i testowania.
Chcemy mieć pewność, że każde urządzenie przejdzie pełny test pakietu CTS (Compatibility Test Suite) z wykorzystaniem narzędzi bezpieczeństwa pamięci, które wykażą, że nie znaleziono żadnych podobnych 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 do tworzenia 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 wyborem 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 do zapewniania bezpieczeństwa pamięci
Android obsługuje wiele narzędzi, które pomagają wykrywać błędy związane z bezpieczeństwem pamięci. Na rysunku poniżej przedstawiono taksonomię dostępnych narzędzi do zapewniania bezpieczeństwa pamięci dostępnych na Androidzie.
Nasze narzędzia obsługują wiele scenariuszy wdrożenia i celów. W poniższej dokumentacji opisano poszczególne narzędzia i podano informacje o tym, jak używać ich w swoich usługach.