Aktualizacje bezpieczeństwa i zasoby

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

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

Zgłaszanie problemów z bezpieczeństwem

Każdy programista, użytkownik Androida lub badacz bezpieczeństwa może powiadomić zespół ds. bezpieczeństwa Androida o potencjalnych problemach 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 lub rozwiązaniu problemu. Jeśli planujesz przesłać poprawkę lub test zestawu testów zgodności (CTS) w celu rozwiązania problemu z bezpieczeństwem, dołącz go do raportu o błędzie i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.

Selekcja błędów

Pierwszym zadaniem związanym z obsługą luki w zabezpieczeniach jest określenie wagi błędu i określenie, który składnik systemu Android jest dotknięty. Ważność określa priorytety problemu, a komponent określa, kto naprawi błąd, kto zostanie powiadomiony i w jaki sposób poprawka zostanie wdrożona dla użytkowników.

Typy kontekstów

Ta tabela zawiera definicje kontekstów bezpieczeństwa 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 uprzywilejowanych.

Typ kontekstu Definicja typu
Ograniczony kontekst Ograniczone środowisko wykonawcze, w którym dostępne są tylko minimalne uprawnienia.

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

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 wiele danych osobowych użytkownika i/lub utrzymuje integralność systemu.

Na przykład aplikacja na Androida z możliwościami, które byłyby zabronione przez domenę SELinux untrusted_app 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 na urządzeniu)
  • ma możliwość ładowania skryptów do komponentu jądra (na przykład eBPF)
  • jest jedną 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 SoC, które zapewniają funkcjonalność krytyczną dla podstawowych przypadków użycia urządzenia (takich jak komórkowe pasma podstawowe, DSP, GPU i procesory ML).
Łańcuch programu ładującego Komponent, który konfiguruje urządzenie podczas rozruchu, a następnie przekazuje kontrolę do systemu operacyjnego Android.
Zaufane środowisko wykonawcze (TEE) Komponent, który ma być chroniony nawet przed wrogim jądrem systemu operacyjnego (na przykład TrustZone i hiperwizory, 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 oraz przed atakiem fizycznym, zgodnie z definicją we Wprowadzenie do bezpiecznych elementów .

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

Powaga

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

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ętowych związanych z bezpieczeństwem (na przykład zabezpieczenia termiczne)
  • Zdalny dostęp do poufnych danych uwierzytelniających używanych do uwierzytelniania usług zdalnych (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 użytkownika (na przykład wykorzystanie błędu w komórkowej usłudze radiowej)
  • Zdalne wykonanie dowolnego kodu w uprzywilejowanym kontekście, łańcuchu bootloadera, THB lub jądrze systemu operacyjnego
  • Zdalne obejście wymagań interakcji użytkownika podczas instalacji pakietu lub równoważne zachowanie
  • Zdalne obejście wymagań dotyczących interakcji użytkownika w przypadku podstawowych ustawień programisty, bezpieczeństwa lub 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 możliwy za pomocą słabych kluczy w SE.
Wysoki
  • Całkowite obejście podstawowej funkcji bezpieczeństwa (na przykład SELinux, FBE lub seccomp )
  • Ogólny obejście do głębokiej obrony lub technologii łagodzenia exploitów w łańcuchu bootloadera, TEE lub SE
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które ujawniają pamięć lub zawartość plików w granicach aplikacji, użytkownika lub profilu
  • Ataki na SE, które skutkują obniżeniem poziomu do mniej bezpiecznej implementacji
  • Obejście ochrony urządzenia/ochrony przywracania ustawień fabrycznych/ograniczeń operatora
  • Obejście wymagań interakcji użytkownika, które są zabezpieczone przez TEE
  • Luka w zabezpieczeniach kryptograficznych, która umożliwia 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 na okaziciela)
  • Lokalne wykonanie dowolnego kodu w uprzywilejowanym kontekście, łańcuch bootloadera, THB lub jądro 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, bezpieczeństwa lub prywatności
  • Lokalne obejście wymagań interakcji użytkownika podczas instalacji pakietu lub równoważne zachowanie
  • 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ń interakcji użytkownika (dostęp do funkcji lub danych, które powinny wymagać inicjacji użytkownika lub zgody użytkownika)
  • Ukierunkowane zapobieganie dostępowi do służb ratowniczych
  • Przesyłanie poufnych informacji przez niezabezpieczony protokół sieciowy (na przykład HTTP i niezaszyfrowany Bluetooth), gdy żądający oczekuje bezpiecznej transmisji. Pamiętaj, że nie dotyczy to szyfrowania Wi-Fi (takiego jak WEP)
  • Nieautoryzowany dostęp do danych zabezpieczonych przez TEE, w tym dostęp możliwy za pomocą słabych kluczy w TEE
Umiarkowany
  • Ogólny obejście do głębokiej obrony lub technologii łagodzenia 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, które są ograniczone do uprzywilejowanego kontekstu)
  • Lokalne wykonanie dowolnego kodu w nieuprzywilejowanym kontekście
  • Lokalne obejście wymagań interakcji użytkownika (dostęp do funkcji lub danych, które normalnie wymagałyby inicjacji użytkownika lub zgody użytkownika)
  • Zdalny dostęp do niechronionych danych (tj. danych normalnie dostępnych dla dowolnej lokalnie zainstalowanej aplikacji)
  • 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 dogłębnej obrony na poziomie użytkownika lub technologii łagodzenia exploitów w nieuprzywilejowanym kontekście
  • Obejście normalnego poziomu ochrony
  • Luka kryptograficzna w niestandardowym użyciu
  • Ogólne obejście funkcji personalizacji na urządzeniu, takich jak Voice Match lub Face Match
  • Niepoprawna dokumentacja, która może prowadzić do powstania luki w zabezpieczeniach
  • Lokalne wykonanie dowolnego kodu w ograniczonym kontekście
  • Tekst zdefiniowany przez system, który zawiera wprowadzający w błąd opis, który stwarza fałszywe oczekiwania dotyczące bezpieczeństwa
Znikomy wpływ na bezpieczeństwo (NSI)
  • Luka w zabezpieczeniach, której wpływ został złagodzony przez co najmniej jeden modyfikator oceny lub zmiany architektury specyficzne dla wersji, tak że efektywna istotność jest niższa niż Niska, chociaż podstawowy problem z kodem może pozostać
  • Każda luka w zabezpieczeniach, która wymaga źle sformatowanego systemu plików, jeśli ten system plików jest zawsze adoptowany/szyfrowany przed użyciem.

Modyfikatory ocen

Podczas gdy powaga luk w zabezpieczeniach jest często łatwa do zidentyfikowania, oceny mogą się zmieniać w zależności od okoliczności.

Powód Efekt
Wymaga uruchomienia w kontekście uprzywilejowanym do przeprowadzenia ataku (nie dotyczy TEE, SE i hiperwizorów, takich jak pKVM) -1 Poziom ciężkości
Szczegółowe informacje dotyczące luki w zabezpieczeniach ograniczają wpływ problemu -1 Poziom ciężkości
Obejście uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia -1 Poziom ciężkości
Konfiguracje kompilatora lub platformy ograniczają lukę w kodzie źródłowym Umiarkowany poziom istotności, jeśli podstawowa luka w zabezpieczeniach 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 momentu włączenia -1 Poziom ciężkości
Wymaga fizycznego dostępu do elementów wewnętrznych urządzenia, gdy urządzenie jest włączone i zostało wcześniej odblokowane -2 Dotkliwość
Atak lokalny, który wymaga odblokowania łańcucha bootloadera Nie wyższy niż niski
Atak lokalny, który wymaga włączenia trybu programisty lub jakichkolwiek trwałych ustawień trybu programisty na urządzeniu (i nie jest błędem samego trybu programisty). Nie wyższy niż niski
Jeśli żadna domena SELinux nie może przeprowadzić operacji zgodnie z SEPolicy dostarczonymi przez Google Znikomy wpływ na bezpieczeństwo

Lokalny kontra proksymalny kontra zdalny

Wektor ataku zdalnego wskazuje, że błąd można wykorzystać bez instalowania aplikacji lub fizycznego dostępu do urządzenia. Obejmuje to błędy, które mogą zostać wywołane podczas przeglądania strony internetowej, czytania wiadomości e-mail, odbierania wiadomości SMS lub łączenia się z wrogą siecią. Na potrzeby naszych ocen dotkliwości uznajemy również „bliższe” wektory ataków za odległe. Należą do nich błędy, które może wykorzystać tylko atakujący, który 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. Ataki oparte na technologii ultraszerokopasmowej (UWB) i NFC uważamy za proksymalne, a zatem zdalne.

Lokalne ataki wymagają, aby ofiara uruchomiła aplikację, instalując ją i uruchamiając lub wyrażając zgodę na uruchomienie aplikacji błyskawicznej . Sparowane urządzenia towarzyszące będą traktowane jako lokalne. Na potrzeby oceny istotności zespół ds. bezpieczeństwa systemu Android bierze również pod uwagę wektory ataków fizycznych jako lokalne. Należą do nich błędy, które może wykorzystać tylko atakujący, który ma 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. Podczas gdy zabezpieczenia warstwy łącza (na przykład szyfrowanie Wi-Fi) zabezpieczają komunikację między urządzeniem a punktem dostępowym, z którym jest ono połączone, nie chronią pozostałych łączy w łańcuchu między urządzeniem a serwerami, z którymi się komunikuje.

Natomiast HTTPS zazwyczaj chroni całą komunikację od końca 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 protokole HTTPS/TLS: samo szyfrowanie Wi-Fi nie wystarcza do większości komunikacji w Internecie.

Uwierzytelnianie biometryczne

Uwierzytelnianie biometryczne to wymagająca przestrzeń, a nawet najlepsze systemy można oszukać przez zbliżenie (patrz Blog programistów Androida: Ekran blokady i ulepszenia uwierzytelniania w Androidzie 11 ). Te oceny istotności rozróżniają dwie klasy ataków i mają na celu odzwierciedlenie rzeczywistego ryzyka dla użytkownika końcowego.

Pierwsza klasa ataków pozwala na obejście uwierzytelniania biometrycznego w uogólniony sposób, bez wysokiej jakości danych biometrycznych od właściciela. Jeśli na przykład atakujący może umieścić kawałek gumy na czytniku linii papilarnych i 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 wiedzy właściciela urządzenia. Ze względu na to, ż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 blokady ekranu).

Inna klasa ataków zazwyczaj obejmuje narzędzie ataku polegające na prezentacji (fałszowanie) oparte na właścicielu urządzenia. Czasami uzyskanie tych informacji biometrycznych jest stosunkowo łatwe (na przykład, jeśli czyjeś zdjęcie profilowe w mediach społecznościowych wystarczy, aby oszukać autoryzację biometryczną, obejście biometryczne otrzyma pełną ocenę istotności). Ale jeśli 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 istotna bariera, że ​​ogranicza liczbę osób dotkniętych atakiem, więc istnieje modyfikator -1 .

SYSTEM_ALERT_WINDOW i przechwytywanie

Aby uzyskać informacje na temat naszych zasad dotyczących SYSTEM_ALERT_WINDOW i tapjackingu, zobacz sekcję „ Luka w zabezpieczeniach SYSTEM_ALERT_WINDOW Tapjacking/overlay na ekranie, który nie ma krytycznego znaczenia dla bezpieczeństwa ” na stronie BugHunter University poświęconej błędom bez wpływu na bezpieczeństwo .

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

Android Automotive OS przyjmuje model bezpieczeństwa dla wielu użytkowników, który różni się od innych formatów. Każdy użytkownik Androida ma być używany 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 dostosować się do takich przypadków użycia, użytkownicy mają domyślnie dostęp do niezbędnych komponentów potrzebnych do korzystania z pojazdu, takich jak ustawienia Wi-Fi i sieci komórkowej.

Składnik, którego dotyczy problem

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

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

Komponent jest również czynnikiem wpływającym na sposób, w jaki użytkownicy otrzymują aktualizacje. Błąd w architekturze lub jądrze wymaga aktualizacji oprogramowania sprzętowego OTA, którą musi przeprowadzić każdy producent OEM. 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 bezpieczeństwa Androida, powiadomimy partnerów Androida o szczegółach problemu i udostępnimy poprawki. Lista obsługiwanych wersji backportu zmienia się z każdą nową wersją Androida. Aby uzyskać listę obsługiwanych urządzeń, skontaktuj się z producentem urządzenia.

Zwolnienie kodu do AOSP

Jeśli błąd bezpieczeństwa występuje w komponencie AOSP, poprawka jest wysyłana do AOSP po udostępnieniu użytkownikom OTA. Poprawki dotyczące problemów o niskiej wadze można przesyłać bezpośrednio do głównej gałęzi 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. Te aktualizacje mogą pochodzić od producenta OEM, który wyprodukował urządzenie, lub od operatora, który świadczy usługi serwisowe dla urządzenia. Aktualizacje urządzenia Google Pixel są dostarczane przez zespół Google Pixel po przejściu przez procedurę testowania akceptacji technicznej przez operatora. Google publikuje również obrazy fabryczne Pixela , które można załadować z boku na urządzenia.

Aktualizowanie usług Google

Oprócz dostarczania łatek usuwających błędy w zabezpieczeniach, zespół ds. bezpieczeństwa Androida przegląda błędy w zabezpieczeniach, 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ć lukę w zabezpieczeniach. W przypadku aplikacji zainstalowanych spoza Google Play urządzenia z usługami Google Play mogą również korzystać z funkcji weryfikacji aplikacji , aby ostrzegać użytkowników przed aplikacjami, 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 są dostępne w witrynach Android Open Source i Developer. Dobre miejsca na start:

Raporty

Czasami zespół Android Security publikuje raporty lub oficjalne dokumenty. Zobacz Raporty bezpieczeństwa , aby uzyskać więcej informacji.

,

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

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

Zgłaszanie problemów z bezpieczeństwem

Każdy programista, użytkownik Androida lub badacz bezpieczeństwa może powiadomić zespół ds. bezpieczeństwa Androida o potencjalnych problemach 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 lub rozwiązaniu problemu. Jeśli planujesz przesłać poprawkę lub test zestawu testów zgodności (CTS) w celu rozwiązania problemu z bezpieczeństwem, dołącz go do raportu o błędzie i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.

Selekcja błędów

Pierwszym zadaniem związanym z obsługą luki w zabezpieczeniach jest określenie wagi błędu i określenie, który składnik systemu Android jest dotknięty. Ważność określa priorytety problemu, a komponent określa, kto naprawi błąd, kto zostanie powiadomiony i w jaki sposób poprawka zostanie wdrożona dla użytkowników.

Typy kontekstów

Ta tabela zawiera definicje kontekstów bezpieczeństwa 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 uprzywilejowanych.

Typ kontekstu Definicja typu
Ograniczony kontekst Ograniczone środowisko wykonawcze, w którym dostępne są tylko minimalne uprawnienia.

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

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 wiele danych osobowych użytkownika i/lub utrzymuje integralność systemu.

Na przykład aplikacja na Androida z możliwościami, które byłyby zabronione przez domenę SELinux untrusted_app 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 na urządzeniu)
  • ma możliwość ładowania skryptów do komponentu jądra (na przykład eBPF)
  • jest jedną 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 SoC, które zapewniają funkcjonalność krytyczną dla podstawowych przypadków użycia urządzenia (takich jak komórkowe pasma podstawowe, DSP, GPU i procesory ML).
Łańcuch programu ładującego Komponent, który konfiguruje urządzenie podczas rozruchu, a następnie przekazuje kontrolę do systemu operacyjnego Android.
Zaufane środowisko wykonawcze (TEE) Komponent, który ma być chroniony nawet przed wrogim jądrem systemu operacyjnego (na przykład TrustZone i hiperwizory, 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 oraz przed atakiem fizycznym, zgodnie z definicją we Wprowadzenie do bezpiecznych elementów .

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

Powaga

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

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ętowych związanych z bezpieczeństwem (na przykład zabezpieczenia termiczne)
  • Zdalny dostęp do poufnych danych uwierzytelniających używanych do uwierzytelniania usług zdalnych (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 użytkownika (na przykład wykorzystanie błędu w komórkowej usłudze radiowej)
  • Zdalne wykonanie dowolnego kodu w uprzywilejowanym kontekście, łańcuchu bootloadera, THB lub jądrze systemu operacyjnego
  • Zdalne obejście wymagań interakcji użytkownika podczas instalacji pakietu lub równoważne zachowanie
  • Zdalne obejście wymagań dotyczących interakcji użytkownika w przypadku podstawowych ustawień programisty, bezpieczeństwa lub 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 możliwy za pomocą słabych kluczy w SE.
Wysoki
  • Całkowite obejście podstawowej funkcji bezpieczeństwa (na przykład SELinux, FBE lub seccomp )
  • Ogólny obejście do głębokiej obrony lub technologii łagodzenia exploitów w łańcuchu bootloadera, TEE lub SE
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które ujawniają pamięć lub zawartość plików w granicach aplikacji, użytkownika lub profilu
  • Ataki na SE, które skutkują obniżeniem poziomu do mniej bezpiecznej implementacji
  • Obejście ochrony urządzenia/ochrony przywracania ustawień fabrycznych/ograniczeń operatora
  • Obejście wymagań interakcji użytkownika, które są zabezpieczone przez TEE
  • Luka w zabezpieczeniach kryptograficznych, która umożliwia 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 na okaziciela)
  • Lokalne wykonanie dowolnego kodu w uprzywilejowanym kontekście, łańcuch bootloadera, THB lub jądro 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, bezpieczeństwa lub prywatności
  • Lokalne obejście wymagań interakcji użytkownika podczas instalacji pakietu lub równoważne zachowanie
  • 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ń interakcji użytkownika (dostęp do funkcji lub danych, które powinny wymagać inicjacji użytkownika lub zgody użytkownika)
  • Ukierunkowane zapobieganie dostępowi do służb ratowniczych
  • Przesyłanie poufnych informacji przez niezabezpieczony protokół sieciowy (na przykład HTTP i niezaszyfrowany Bluetooth), gdy żądający oczekuje bezpiecznej transmisji. Pamiętaj, że nie dotyczy to szyfrowania Wi-Fi (takiego jak WEP)
  • Nieautoryzowany dostęp do danych zabezpieczonych przez TEE, w tym dostęp możliwy za pomocą słabych kluczy w TEE
Umiarkowany
  • Ogólny obejście do głębokiej obrony lub technologii łagodzenia 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, które są ograniczone do uprzywilejowanego kontekstu)
  • Lokalne wykonanie dowolnego kodu w nieuprzywilejowanym kontekście
  • Lokalne obejście wymagań interakcji użytkownika (dostęp do funkcji lub danych, które normalnie wymagałyby inicjacji użytkownika lub zgody użytkownika)
  • Zdalny dostęp do niechronionych danych (tj. danych normalnie dostępnych dla dowolnej lokalnie zainstalowanej aplikacji)
  • 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 dogłębnej obrony na poziomie użytkownika lub technologii łagodzenia exploitów w nieuprzywilejowanym kontekście
  • Obejście normalnego poziomu ochrony
  • Luka kryptograficzna w niestandardowym użyciu
  • Ogólne obejście funkcji personalizacji na urządzeniu, takich jak Voice Match lub Face Match
  • Niepoprawna dokumentacja, która może prowadzić do powstania luki w zabezpieczeniach
  • Lokalne wykonanie dowolnego kodu w ograniczonym kontekście
  • Tekst zdefiniowany przez system, który zawiera wprowadzający w błąd opis, który stwarza fałszywe oczekiwania dotyczące bezpieczeństwa
Znikomy wpływ na bezpieczeństwo (NSI)
  • Luka w zabezpieczeniach, której wpływ został złagodzony przez co najmniej jeden modyfikator oceny lub zmiany architektury specyficzne dla wersji, tak że efektywna istotność jest niższa niż Niska, chociaż podstawowy problem z kodem może pozostać
  • Każda luka w zabezpieczeniach, która wymaga źle sformatowanego systemu plików, jeśli ten system plików jest zawsze adoptowany/szyfrowany przed użyciem.

Modyfikatory ocen

Podczas gdy powaga luk w zabezpieczeniach jest często łatwa do zidentyfikowania, oceny mogą się zmieniać w zależności od okoliczności.

Powód Efekt
Wymaga uruchomienia w kontekście uprzywilejowanym do przeprowadzenia ataku (nie dotyczy TEE, SE i hiperwizorów, takich jak pKVM) -1 Poziom ciężkości
Szczegółowe informacje dotyczące luki w zabezpieczeniach ograniczają wpływ problemu -1 Poziom ciężkości
Obejście uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia -1 Poziom ciężkości
Konfiguracje kompilatora lub platformy ograniczają lukę w kodzie źródłowym Umiarkowany poziom istotności, jeśli podstawowa luka w zabezpieczeniach 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 momentu włączenia -1 Poziom ciężkości
Wymaga fizycznego dostępu do elementów wewnętrznych urządzenia, gdy urządzenie jest włączone i zostało wcześniej odblokowane -2 Dotkliwość
Atak lokalny, który wymaga odblokowania łańcucha bootloadera Nie wyższy niż niski
Atak lokalny, który wymaga włączenia trybu programisty lub jakichkolwiek trwałych ustawień trybu programisty na urządzeniu (i nie jest błędem samego trybu programisty). Nie wyższy niż niski
Jeśli żadna domena SELinux nie może przeprowadzić operacji zgodnie z SEPolicy dostarczonymi przez Google Znikomy wpływ na bezpieczeństwo

Lokalny kontra proksymalny kontra zdalny

Wektor ataku zdalnego wskazuje, że błąd można wykorzystać bez instalowania aplikacji lub fizycznego dostępu do urządzenia. Obejmuje to błędy, które mogą zostać wywołane podczas przeglądania strony internetowej, czytania wiadomości e-mail, odbierania wiadomości SMS lub łączenia się z wrogą siecią. Na potrzeby naszych ocen dotkliwości uznajemy również „bliższe” wektory ataków za odległe. Należą do nich błędy, które może wykorzystać tylko atakujący, który 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. Ataki oparte na technologii ultraszerokopasmowej (UWB) i NFC uważamy za proksymalne, a zatem zdalne.

Lokalne ataki wymagają, aby ofiara uruchomiła aplikację, instalując ją i uruchamiając lub wyrażając zgodę na uruchomienie aplikacji błyskawicznej . Sparowane urządzenia towarzyszące będą traktowane jako lokalne. Na potrzeby oceny istotności zespół ds. bezpieczeństwa systemu Android bierze również pod uwagę wektory ataków fizycznych jako lokalne. Należą do nich błędy, które może wykorzystać tylko atakujący, który ma 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. Podczas gdy zabezpieczenia warstwy łącza (na przykład szyfrowanie Wi-Fi) zabezpieczają komunikację między urządzeniem a punktem dostępowym, z którym jest ono połączone, nie chronią pozostałych łączy w łańcuchu między urządzeniem a serwerami, z którymi się komunikuje.

Natomiast HTTPS zazwyczaj chroni całą komunikację od końca 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 protokole HTTPS/TLS: samo szyfrowanie Wi-Fi nie wystarcza do większości komunikacji w Internecie.

Uwierzytelnianie biometryczne

Uwierzytelnianie biometryczne to wymagająca przestrzeń, a nawet najlepsze systemy można oszukać przez zbliżenie (patrz Blog programistów Androida: Ekran blokady i ulepszenia uwierzytelniania w Androidzie 11 ). Te oceny istotności rozróżniają dwie klasy ataków i mają na celu odzwierciedlenie rzeczywistego ryzyka dla użytkownika końcowego.

Pierwsza klasa ataków pozwala na obejście uwierzytelniania biometrycznego w uogólniony sposób, bez wysokiej jakości danych biometrycznych od właściciela. Jeśli na przykład atakujący może umieścić kawałek gumy na czytniku linii papilarnych i 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 wiedzy właściciela urządzenia. Ze względu na to, ż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 blokady ekranu).

Inna klasa ataków zazwyczaj obejmuje narzędzie ataku polegające na prezentacji (fałszowanie) oparte na właścicielu urządzenia. Czasami uzyskanie tych informacji biometrycznych jest stosunkowo łatwe (na przykład, jeśli czyjeś zdjęcie profilowe w mediach społecznościowych wystarczy, aby oszukać autoryzację biometryczną, obejście biometryczne otrzyma pełną ocenę istotności). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.

SYSTEM_ALERT_WINDOW and Tapjacking

For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.

Multi-user security in Android Automotive OS

Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.

Affected component

The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.

Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.

The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.

Notifying partners

When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.

Releasing code to AOSP

If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.

Receiving Android updates

Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.

Updating Google services

In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.

Other resources

Information for Android app developers: https://developer.android.com

Security information exists throughout the Android Open Source and Developer sites. Good places to start:

Reports

Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.