Aktualizacje i zasoby dotyczące zabezpieczeń

Zespół ds. bezpieczeństwa Androida jest odpowiedzialny za zarządzanie lukami w zabezpieczeniach wykrytymi na platformie Android i wielu podstawowych aplikacjach Androida dostarczanych z urządzeniami z Androidem.

Zespół ds. bezpieczeństwa Androida znajduje luki w zabezpieczeniach na podstawie wewnętrznych badań, a także reaguje na błędy zgłaszane przez strony trzecie. Źródła błędów zewnętrznych obejmują problemy zgłaszane za pośrednictwem formularza dotyczącego luk w zabezpieczeniach , opublikowane i wcześniej opublikowane badania akademickie, opiekunowie projektów open source, powiadomienia od naszych partnerów będących producentami urządzeń oraz publicznie ujawnione problemy publikowane na blogach i mediach społecznościowych.

Zgłaszanie problemów związanych z bezpieczeństwem

Każdy programista, użytkownik Androida lub badacz bezpieczeństwa może powiadomić zespół ds. bezpieczeństwa Androida o potencjalnych problemach związanych z bezpieczeństwem za pomocą formularza dotyczącego luk w zabezpieczeniach .

Błędy oznaczone jako problemy z bezpieczeństwem nie są widoczne z zewnątrz, ale mogą ostatecznie stać się widoczne po ocenie i rozwiązaniu problemu. Jeśli planujesz przesłać łatkę lub test pakietu testów zgodności (CTS) w celu rozwiązania problemu bezpieczeństwa, dołącz go do raportu o błędzie i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.

Wybieranie błędów

Pierwszym zadaniem w przypadku luki w zabezpieczeniach jest określenie wagi błędu i tego, którego składnika Androida dotyczy. Ważność określa priorytet problemu, a komponent określa, kto naprawia błąd, kto jest powiadamiany i w jaki sposób poprawka jest wdrażana wśród użytkowników.

Typy kontekstu

W tabeli tej przedstawiono definicje kontekstów zabezpieczeń sprzętu i oprogramowania. Kontekst można zdefiniować na podstawie wrażliwości danych, które zwykle przetwarza, lub obszaru, w którym działa. Nie wszystkie konteksty zabezpieczeń mają zastosowanie do wszystkich systemów. Ta tabela jest uporządkowana od najmniej do najbardziej uprzywilejowanego.

Typ kontekstu Definicja typu
Ograniczony kontekst Środowisko o ograniczonym wykonywaniu, w którym zapewniane są tylko minimalne uprawnienia.

Na przykład zaufane aplikacje przetwarzające niezaufane dane w środowisku piaskownicy.
Nieuprzywilejowany kontekst Typowe środowisko wykonawcze oczekiwane przez kod nieuprzywilejowany.

Na przykład aplikacja na Androida działająca w domenie SELinux z atrybutem untrusted_app_all .
Uprzywilejowany kontekst Uprzywilejowane środowisko wykonawcze, które może mieć dostęp do podwyższonych uprawnień, obsługuje informacje umożliwiające identyfikację wielu użytkowników i/lub utrzymuje integralność systemu.

Na przykład aplikacja na Androida z możliwościami, które byłyby zabronione przez domenę untrusted_app SELinux lub z dostępem do privileged|signature .
Jądro systemu operacyjnego Funkcjonalność, która:
  • jest częścią jądra
  • działa w tym samym kontekście procesora co jądro (na przykład sterowniki urządzeń)
  • ma bezpośredni dostęp do pamięci jądra (na przykład komponentów sprzętowych urządzenia)
  • ma możliwość ładowania skryptów do komponentu jądra (na przykład eBPF)
  • to jedna z niewielu usług użytkownika uważanych za odpowiedniki jądra (takich jak apexd , bpfloader , init , ueventd i vold ).
Zaufana baza sprzętu (THB) Dyskretne komponenty sprzętowe, zwykle w układzie SoC, które zapewniają funkcjonalność krytyczną dla podstawowych zastosowań urządzenia (takich jak komórkowe pasma podstawowe, procesory DSP, procesory graficzne i procesory ML).
Łańcuch bootloadera Komponent, który konfiguruje urządzenie podczas uruchamiania, a następnie przekazuje kontrolę do systemu operacyjnego Android.
Zaufane środowisko wykonawcze (TEE) Komponent zaprojektowany tak, aby był chroniony nawet przed wrogim jądrem systemu operacyjnego (na przykład TrustZone i hypervisory, takie jak pKVM, które chronią maszyny wirtualne przed jądrem systemu operacyjnego).
Bezpieczna enklawa / bezpieczny element (SE) Opcjonalny komponent sprzętowy zaprojektowany w celu ochrony przed wszystkimi innymi komponentami urządzenia i przed atakiem fizycznym, zgodnie z definicją we wstępie do elementów bezpiecznych .

Obejmuje to chip Titan-M obecny w niektórych urządzeniach z Androidem.

Powaga

Waga błędu zazwyczaj odzwierciedla potencjalne szkody, które mogą wystąpić, jeśli błąd zostanie pomyślnie wykorzystany. Aby określić dotkliwość, użyj następujących kryteriów.

Ocena Konsekwencje udanej eksploatacji
Krytyczny
  • Wykonanie dowolnego kodu w TEE lub SE
  • Obejście mechanizmów oprogramowania zaprojektowanych w celu zapobiegania nieprawidłowemu działaniu oprogramowania lub komponentów sprzętu związanych z bezpieczeństwem (na przykład zabezpieczeń termicznych)
  • Zdalny dostęp do poufnych danych uwierzytelniających używanych do zdalnego uwierzytelniania usług (na przykład haseł do kont lub tokenów na okaziciela)
  • Zdalne wykonanie dowolnego kodu w kontekście pasma podstawowego sieci komórkowej bez interakcji z użytkownikiem (na przykład poprzez wykorzystanie błędu w usłudze łączności komórkowej)
  • Zdalne wykonanie dowolnego kodu w uprzywilejowanym kontekście, łańcuchu programu ładującego, THB lub jądrze systemu operacyjnego
  • Zdalne obejście wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub równoważnego zachowania
  • Zdalne obejście wymagań dotyczących interakcji użytkownika w zakresie podstawowych ustawień programisty, zabezpieczeń i prywatności
  • Zdalna trwała odmowa usługi (trwała, wymagająca ponownego flashowania całego systemu operacyjnego lub przywrócenia ustawień fabrycznych)
  • Zdalne obejście bezpiecznego rozruchu
  • Nieautoryzowany dostęp do danych zabezpieczonych przez SE, w tym dostęp umożliwiony przez słabe klucze w SE.
Wysoki
  • Całkowite ominięcie podstawowej funkcji bezpieczeństwa (na przykład SELinux, FBE lub seccomp )
  • Ogólne obejście dla głębokiej obrony lub technologii ograniczania exploitów w łańcuchu programu ładującego, TEE lub SE
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które ujawniają zawartość pamięci lub plików poza granicami aplikacji, użytkownika lub profilu
  • Ataki na SE skutkujące przejściem na mniej bezpieczną implementację
  • Przejście ze zdalnie dostępnego, skompromitowanego oprogramowania sprzętowego typu bare-metal (np. pasma podstawowego, procesora CP/procesora komunikacyjnego) do jądra procesora aplikacji (AP) lub mechanizmów obejścia zaprojektowanych w celu izolowania oprogramowania sprzętowego typu bare-metal od jądra punktu dostępowego
  • Obejście ochrony urządzenia/ochrony przywracania ustawień fabrycznych/ograniczeń operatora
  • Ominięcie wymagań dotyczących interakcji użytkownika, które są zabezpieczone przez TEE
  • Luka kryptograficzna umożliwiająca ataki na protokoły typu end-to-end, w tym ataki na zabezpieczenia warstwy transportowej (TLS) i Bluetooth (BT).
  • Lokalny dostęp do poufnych danych uwierzytelniających używanych do uwierzytelniania usług zdalnych (na przykład haseł do kont lub tokenów okaziciela)
  • Lokalne wykonanie dowolnego kodu w kontekście uprzywilejowanym, łańcuchu programu ładującego, THB lub jądrze systemu operacyjnego
  • Lokalne obejście bezpiecznego rozruchu
  • Obejście ekranu blokady
  • Lokalne obejście wymagań dotyczących interakcji użytkownika w przypadku podstawowych ustawień programisty, zabezpieczeń lub prywatności
  • Lokalne obejście wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub równoważnego zachowania
  • Lokalna trwała odmowa usługi (trwała, wymagająca ponownego flashowania całego systemu operacyjnego lub przywrócenia ustawień fabrycznych)
  • Zdalny dostęp do chronionych danych (czyli danych ograniczonych do uprzywilejowanego kontekstu)
  • Zdalne wykonanie dowolnego kodu w nieuprzywilejowanym kontekście
  • Zdalne zapobieganie dostępowi do usługi komórkowej lub Wi-Fi bez interakcji użytkownika (na przykład awaria komórkowej usługi radiowej z powodu zniekształconego pakietu)
  • Zdalne obejście wymagań dotyczących interakcji użytkownika (dostęp do funkcjonalności lub danych, które powinny wymagać inicjacji użytkownika lub jego zgody)
  • Ukierunkowane zapobieganie dostępowi do służb ratunkowych
  • Przesyłanie poufnych informacji za pośrednictwem niezabezpieczonego protokołu sieciowego (na przykład HTTP i niezaszyfrowanego Bluetooth), gdy osoba żądająca oczekuje bezpiecznej transmisji. Należy pamiętać, że nie dotyczy to szyfrowania Wi-Fi (takiego jak WEP)
  • Nieautoryzowany dostęp do danych zabezpieczonych przez TEE, w tym dostęp umożliwiony przez słabe klucze w TEE
Umiarkowany
  • Ogólne obejście dla dogłębnej ochrony lub technologii ograniczania exploitów w uprzywilejowanym kontekście, THB lub jądrze systemu operacyjnego
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które ujawniają stan procesu lub metadane w granicach aplikacji, użytkownika lub profilu
  • Omijanie szyfrowania lub uwierzytelniania Wi-Fi
  • Luka kryptograficzna w standardowych prymitywach kryptograficznych, która umożliwia wyciek zwykłego tekstu (nie prymitywów używanych w TLS)
  • Lokalny dostęp do chronionych danych (czyli danych ograniczonych do uprzywilejowanego kontekstu)
  • Lokalne wykonanie dowolnego kodu w nieuprzywilejowanym kontekście
  • Lokalne obejście wymagań dotyczących interakcji użytkownika (dostęp do funkcjonalności lub danych, które normalnie wymagałyby inicjacji użytkownika lub jego zgody)
  • Zdalny dostęp do niechronionych danych (to znaczy danych, do których zwykle ma dostęp każda lokalnie zainstalowana aplikacja)
  • Zdalne wykonanie dowolnego kodu w ograniczonym kontekście
  • Zdalna tymczasowa odmowa usługi urządzenia (zdalne zawieszenie lub ponowne uruchomienie)
Niski
  • Ogólne obejście dla dogłębnej ochrony na poziomie użytkownika lub technologii ograniczania zagrożeń w nieuprzywilejowanym kontekście
  • Obejście normalnego poziomu ochrony
  • Podatność kryptograficzna w przypadku niestandardowego użycia
  • Ogólne obejście funkcji personalizacji na urządzeniu, takich jak Voice Match lub Face Match
  • Nieprawidłowa dokumentacja, która może prowadzić do luki w zabezpieczeniach
  • Lokalne wykonanie dowolnego kodu w ograniczonym kontekście
  • Tekst zdefiniowany przez system zawierający wprowadzający w błąd opis tworzący fałszywe oczekiwania dotyczące bezpieczeństwa
Znikomy wpływ na bezpieczeństwo (NSI)
  • Luka, której wpływ został złagodzony przez jeden lub więcej modyfikatorów oceny lub zmiany w architekturze specyficznej dla wersji w taki sposób, że efektywna istotność jest poniżej Niska, chociaż podstawowy problem z kodem może pozostać
  • Jakakolwiek luka wymagająca zniekształconego systemu plików, jeśli ten system plików jest zawsze adoptowany/szyfrowany przed użyciem.
  • Lokalna tymczasowa odmowa usługi , na przykład gdy problem można rozwiązać poprzez ponowne uruchomienie urządzenia lub odinstalowanie aplikacji wywołującej.

Modyfikatory ocen

Chociaż wagę luk w zabezpieczeniach często łatwo jest zidentyfikować, oceny mogą się zmieniać w zależności od okoliczności.

Powód Efekt
Aby wykonać atak, wymaga działania w kontekście uprzywilejowanym (nie dotyczy TEE, SE i hypervisorów, takich jak pKVM) -1 Dotkliwość
Szczegóły dotyczące luki w zabezpieczeniach ograniczają wpływ problemu -1 Dotkliwość
Obejście uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia -1 Dotkliwość
Konfiguracje kompilatora lub platformy łagodzą lukę w kodzie źródłowym Umiarkowana ważność, jeśli podstawowa luka jest umiarkowana lub wyższa
Wymaga fizycznego dostępu do elementów wewnętrznych urządzenia i jest nadal możliwy, jeśli urządzenie jest wyłączone lub nie zostało odblokowane od czasu włączenia -1 Dotkliwość
Wymaga fizycznego dostępu do elementów wewnętrznych urządzenia, gdy jest ono włączone i zostało wcześniej odblokowane -2 Dotkliwość
Lokalny atak wymagający odblokowania łańcucha bootloadera Nie wyżej niż Niska
Lokalny atak wymagający włączonego trybu programisty lub jakichkolwiek trwałych ustawień trybu programisty na urządzeniu (i nie jest błędem w samym trybie programisty). Nie wyżej niż Niska
Jeśli żadna domena SELinux nie może przeprowadzić operacji zgodnie z SEPolicy udostępnioną przez Google Znikomy wpływ na bezpieczeństwo

Lokalne kontra bliższe i odległe

Wektor ataku zdalnego wskazuje, że błąd można wykorzystać bez instalowania aplikacji lub bez fizycznego dostępu do urządzenia. Obejmuje to błędy, które mogą zostać wywołane przez przeglądanie strony internetowej, czytanie wiadomości e-mail, odbieranie wiadomości SMS lub łączenie się z wrogą siecią. Na potrzeby naszych ocen ważności „bliższe” wektory ataków uznajemy również za odległe. Należą do nich błędy, które może wykorzystać jedynie osoba atakująca, która fizycznie znajduje się w pobliżu urządzenia docelowego, na przykład błąd wymagający wysyłania zniekształconych pakietów Wi-Fi lub Bluetooth. Uważamy ataki ultraszerokopasmowe (UWB) i NFC za bliskie, a zatem odległe.

Ataki lokalne wymagają od ofiary uruchomienia aplikacji poprzez zainstalowanie i uruchomienie aplikacji lub wyrażenie zgody na uruchomienie aplikacji błyskawicznej . Sparowane urządzenia towarzyszące będą uznawane za lokalne. Na potrzeby oceny ważności zespół ds. bezpieczeństwa Androida uwzględnia również wektory ataków fizycznych jako lokalne. Należą do nich błędy, które może wykorzystać jedynie osoba atakująca mając fizyczny dostęp do urządzenia, na przykład błąd na ekranie blokady lub taki, który wymaga podłączenia kabla USB.

Bezpieczeństwo sieci

Android zakłada, że ​​wszystkie sieci są wrogie i mogą przeprowadzać ataki lub szpiegować ruch. Chociaż zabezpieczenia warstwy łącza (na przykład szyfrowanie Wi-Fi) zabezpieczają komunikację między urządzeniem a punktem dostępu, do którego jest ono podłączone, nie zabezpieczają one w żaden sposób pozostałych łączy w łańcuchu między urządzeniem a serwerami, z którymi się komunikuje.

Z kolei protokół HTTPS zazwyczaj chroni całą komunikację od początku do końca, szyfrując dane u źródła, a następnie odszyfrowując je i weryfikując dopiero po dotarciu do miejsca docelowego. Z tego powodu luki zagrażające bezpieczeństwu sieci warstwy łącza są oceniane jako mniej poważne niż luki w zabezpieczeniach protokołu HTTPS/TLS: samo szyfrowanie Wi-Fi jest niewystarczające w przypadku większości komunikacji w Internecie.

Uwierzytelnianie biometryczne

Uwierzytelnianie biometryczne to trudna dziedzina i nawet najlepsze systemy mogą dać się oszukać przez prawie dopasowanie (zobacz blog Android Developers: Blokada ekranu i ulepszenia uwierzytelniania w Androidzie 11 ). Te wskaźniki ważności rozróżniają dwie klasy ataków i mają odzwierciedlać rzeczywiste ryzyko dla użytkownika końcowego.

Pierwsza klasa ataków pozwala w sposób uogólniony ominąć uwierzytelnianie biometryczne, bez uzyskania wysokiej jakości danych biometrycznych od właściciela. Jeśli na przykład osoba atakująca może umieścić kawałek gumy na czujniku odcisków palców, a on zapewnia dostęp do urządzenia na podstawie pozostałości pozostawionych na czujniku, jest to prosty atak, który można przeprowadzić na dowolnym podatnym urządzeniu. Nie wymaga żadnej wiedzy właściciela urządzenia. Biorąc pod uwagę, że można go uogólnić i potencjalnie wpłynąć na większą liczbę użytkowników, atak ten otrzymuje pełną ocenę ważności (na przykład Wysoka w przypadku obejścia ekranu blokady).

Druga klasa ataków zazwyczaj obejmuje instrument ataku prezentacyjnego (parodię) oparty na właścicielu urządzenia. Czasami uzyskanie takich informacji biometrycznych jest stosunkowo łatwe (na przykład, jeśli czyjeś zdjęcie profilowe w mediach społecznościowych wystarczy, aby oszukać uwierzytelnienie biometryczne, wówczas obejście biometryczne otrzyma pełną ocenę ważności). Jeśli jednak atakujący musiałby uzyskać dane biometryczne bezpośrednio od właściciela urządzenia (na przykład skan twarzy w podczerwieni), jest to na tyle znacząca bariera, że ​​ogranicza liczbę osób dotkniętych atakiem, dlatego istnieje modyfikator -1 .

SYSTEM_ALERT_WINDOW i Tapjacking

Informacje na temat naszych zasad dotyczących SYSTEM_ALERT_WINDOW i tapjackingu można znaleźć w sekcji „ Luka w zabezpieczeniach SYSTEM_ALERT_WINDOW w zakresie Tapjacking/nakładka na ekranie niekrytycznym dla bezpieczeństwa ” na stronie BugHunter University Błędy bez wpływu na bezpieczeństwo .

Bezpieczeństwo wielu użytkowników w systemie operacyjnym Android Automotive

System operacyjny Android Automotive przyjmuje model bezpieczeństwa dla wielu użytkowników, inny niż w innych obudowach. Każdy użytkownik Androida jest przeznaczony do użytku przez inną osobę fizyczną. Na przykład tymczasowego użytkownika-gościa można przypisać znajomemu, który pożycza pojazd od właściciela samochodu. Aby uwzględnić takie przypadki użycia, użytkownicy domyślnie mają dostęp do niezbędnych komponentów potrzebnych do korzystania z pojazdu, takich jak ustawienia Wi-Fi i sieci komórkowej.

Dotknięty komponent

Zespół programistów odpowiedzialny za naprawienie błędu zależy od tego, w którym komponencie występuje błąd. Może to być podstawowy komponent platformy Android, sterownik jądra dostarczony przez producenta oryginalnego sprzętu (OEM) lub jedna z aplikacji ładowanych fabrycznie na urządzeniach Pixel .

Błędy w kodzie AOSP są naprawiane przez zespół inżynierów Androida. Błędy o niskiej istotności, błędy w niektórych komponentach lub błędy, które są już publicznie znane, można naprawić bezpośrednio w publicznie dostępnej głównej gałęzi AOSP; w przeciwnym razie zostaną one najpierw naprawione w naszych wewnętrznych repozytoriach.

Komponent ma również wpływ na to, w jaki sposób użytkownicy otrzymują aktualizacje. Błąd w frameworku lub jądrze wymaga bezprzewodowej aktualizacji oprogramowania sprzętowego (OTA), którą każdy producent OEM musi przesłać. Błąd w aplikacji lub bibliotece opublikowanej w Google Play (na przykład Gmail, Usługi Google Play lub WebView) może zostać wysłany do użytkowników Androida jako aktualizacja z Google Play.

Powiadamianie partnerów

Gdy luka w zabezpieczeniach AOSP zostanie naprawiona w Biuletynie zabezpieczeń Androida, powiadomimy partnerów Androida o szczegółach problemu i udostępnimy poprawki. Lista wersji obsługiwanych przez backport zmienia się wraz z każdą nową wersją Androida. Skontaktuj się z producentem urządzenia, aby uzyskać listę obsługiwanych urządzeń.

Udostępnienie kodu do AOSP

Jeśli błąd bezpieczeństwa występuje w komponencie AOSP, poprawka jest przekazywana do AOSP po udostępnieniu użytkownikom wersji OTA. Poprawki dotyczące problemów o niskiej wadze można przesyłać bezpośrednio do głównego oddziału AOSP, zanim poprawka będzie dostępna dla urządzeń za pośrednictwem OTA.

Odbieranie aktualizacji Androida

Aktualizacje systemu Android są zazwyczaj dostarczane do urządzeń za pośrednictwem pakietów aktualizacji OTA. Aktualizacje te mogą pochodzić od producenta OEM, który wyprodukował urządzenie, lub od operatora świadczącego usługi serwisowe dla urządzenia. Aktualizacje urządzenia Google Pixel pochodzą od zespołu Google Pixel po przejściu procedury testów akceptacji technicznej u operatora. Google publikuje także obrazy fabryczne Pixela , które można wgrać z boku na urządzenia.

Aktualizowanie usług Google

Oprócz dostarczania poprawek na błędy bezpieczeństwa zespół ds. bezpieczeństwa Androida sprawdza błędy bezpieczeństwa, aby określić, czy istnieją inne sposoby ochrony użytkowników. Na przykład Google Play skanuje wszystkie aplikacje i usuwa każdą aplikację, która próbuje wykorzystać błąd bezpieczeństwa. W przypadku aplikacji zainstalowanych spoza Google Play urządzenia z Usługami Google Play mogą także korzystać z funkcji Weryfikuj aplikacje , aby ostrzegać użytkowników o aplikacjach, które mogą być potencjalnie szkodliwe.

Inne zasoby

Informacje dla twórców aplikacji na Androida: https://developer.android.com

Informacje dotyczące bezpieczeństwa znajdują się w witrynach Android Open Source i dla programistów. Dobre miejsca na początek:

Raporty

Czasami zespół ds. bezpieczeństwa Androida publikuje raporty lub oficjalne dokumenty. Więcej szczegółów znajdziesz w Raportach bezpieczeństwa .