Aktualizacje bezpieczeństwa i zasoby

Zespół ds. bezpieczeństwa systemu Android jest odpowiedzialny za zarządzanie lukami w zabezpieczeniach wykrytymi na platformie Android i wieloma podstawowymi aplikacjami na Androida dołączonymi do urządzeń z systemem Android.

Zespół ds. bezpieczeństwa Androida znajduje luki w zabezpieczeniach poprzez wewnętrzne badania, a także reaguje na błędy zgłoszone przez strony trzecie. Źródła błędów zewnętrznych obejmują problemy zgłoszone za pomocą szablonu problemu dotyczącego bezpieczeństwa Androida , opublikowane i wstępnie opublikowane badania naukowe, opiekunowie projektów open source, powiadomienia od naszych partnerów będących producentami urządzeń oraz problemy ujawnione publicznie 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 zabezpieczeniami za pomocą formularza zgłaszania luk w zabezpieczeniach .

Błędy oznaczone jako problemy z zabezpieczeniami nie są widoczne zewnętrznie, ale ostatecznie mogą zostać uwidocznione po ocenie lub rozwiązaniu problemu. Jeśli planujesz przesłać poprawkę lub test Compatibility Test Suite (CTS) w celu rozwiązania problemu związanego z bezpieczeństwem, dołącz go do zgłoszenia błędu i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.

Błędy selekcji

Pierwszym zadaniem związanym z obsługą luki w zabezpieczeniach jest zidentyfikowanie wagi błędu i określenie składnika systemu Android, którego dotyczy. Ważność określa priorytet problemu, a składnik określa, kto naprawi błąd, kto zostanie powiadomiony i jak poprawka zostanie wdrożona u użytkowników.

Rodzaje kontekstu

Ta tabela zawiera 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 uprzywilejowanej.

Typ kontekstu Definicja typu
Ograniczony kontekst Ograniczone środowisko wykonywania, w którym zapewnione 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 dane 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ę 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 (np. komponentów sprzętowych na urządzeniu)
  • posiada możliwość ładowania skryptów do komponentu jądra (np. eBPF)
  • jest jedną z kilku usług użytkownika, które są uważane za równoważne jądru (takie jak apexd , bpfloader , init , ueventd i vold ).
Zaufana baza sprzętowa (THB) Oddzielne komponenty sprzętowe, zwykle na SoC, które zapewniają funkcjonalność krytyczną dla podstawowych przypadków użycia urządzenia (takie jak komórkowe pasma podstawowe, procesory DSP, procesory graficzne i procesory ML).
Łańcuch bootloadera Składnik, 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 hipernadzorcami, takimi jak pKVM, które chronią maszyny wirtualne przed jądrem systemu operacyjnego).
Bezpieczna Enklawa / Bezpieczny Element (SE) Opcjonalny składnik sprzętowy przeznaczony do ochrony przed wszystkimi innymi składnikami urządzenia oraz przed fizycznym atakiem, zgodnie z definicją we Wstępie do bezpiecznych elementów .

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

Surowość

Powaga błędu ogólnie odzwierciedla potencjalną szkodę, która mogłaby wystąpić, gdyby błąd został pomyślnie wykorzystany. Użyj poniższych kryteriów, aby określić wagę.

Ocena Konsekwencja 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 komórkowego pasma podstawowego 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ądra systemu operacyjnego
  • Zdalne omijanie wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub równoważnego zachowania
  • Zdalne omijanie wymagań dotyczących interakcji z użytkownikiem dla podstawowych ustawień programisty, zabezpieczeń lub prywatności
  • Zdalna, trwała odmowa usługi (stała, wymagająca przeprogramowania 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 ominięcie podstawowej funkcji bezpieczeństwa (na przykład SELinux, FBE lub seccomp )
  • Ogólne obejście w celu obrony w głąb lub wykorzystania technologii łagodzącej w łańcuchu bootloadera, TEE lub SE
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które ujawniają zawartość pamięci lub plików poza granicami aplikacji, użytkowników lub profili
  • Ataki na SE, które skutkują przejściem na mniej bezpieczną implementację
  • Obejście ochrony urządzenia/ochrona przywracania ustawień fabrycznych/ograniczenia operatora
  • Obejście wymagań dotyczących interakcji użytkownika, które są zabezpieczane przez TEE
  • Luka kryptograficzna umożliwiająca ataki na protokoły 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ńcuch bootloadera, THB lub jądro systemu operacyjnego
  • Lokalne obejście bezpiecznego rozruchu
  • Pomijanie ekranu blokady
  • Lokalne obejście wymagań dotyczących interakcji z użytkownikiem dla 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 (stała, wymagająca przeprogramowania 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 omijanie wymagań dotyczących interakcji użytkownika (dostęp do funkcji lub danych, które powinny wymagać inicjacji użytkownika lub pozwolenia użytkownika)
  • Ukierunkowane zapobieganie dostępowi do służb ratunkowych
  • Przesyłanie poufnych informacji przez niezabezpieczony protokół sieciowy (na przykład HTTP i nieszyfrowany 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ólne obejście w celu zapewnienia dogłębnej ochrony lub technologii łagodzącej zagrożenia w kontekście uprzywilejowanym, THB lub jądra 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 omijanie wymagań dotyczących interakcji użytkownika (dostęp do funkcji lub danych, które normalnie wymagałyby inicjacji użytkownika lub pozwolenia użytkownika)
  • Zdalny dostęp do niezabezpieczonych danych (czyli danych zwykle 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 w celu dogłębnej ochrony na poziomie użytkownika lub wykorzystania technologii łagodzenia skutków w nieuprzywilejowanym kontekście
  • Obejście normalnego uprawnienia poziomu ochrony
  • Luka kryptograficzna w niestandardowym użyciu
  • Ogólne pomijanie 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, który zawiera wprowadzający w błąd opis, który tworzy fałszywe oczekiwania dotyczące bezpieczeństwa
Znikomy wpływ na bezpieczeństwo (NSI)
  • Luka, której wpływ został złagodzony przez co najmniej jeden modyfikator oceny lub zmiany architektury specyficzne dla wersji, tak że efektywna ważność jest niższa niż Niska, chociaż podstawowy problem z kodem może pozostać
  • Każda usterka, która wymaga zniekształconego systemu plików, jeśli ten system plików jest zawsze adoptowany/zaszyfrowany przed użyciem.

Modyfikatory oceny

Chociaż waga 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 uprzywilejowanym kontekście do wykonania ataku (nie dotyczy TEE, SE i hipernadzorców, takich jak pKVM) -1 dotkliwość
Szczegóły dotyczące luk w zabezpieczeniach ograniczają wpływ problemu -1 dotkliwość
Ominięcie uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia -1 dotkliwość
Konfiguracje kompilatora lub platformy ograniczają lukę w kodzie źródłowym Umiarkowane Istotność, jeśli podstawowa podatność jest Umiarkowana lub wyższa
Wymaga fizycznego dostępu do wewnętrznych elementów urządzenia i jest nadal możliwe, jeśli urządzenie jest wyłączone lub nie zostało odblokowane od momentu włączenia -1 dotkliwość
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 w ramach dostarczonej przez Google SEPolicy Znikomy wpływ na bezpieczeństwo

Lokalne kontra proksymalne kontra zdalne

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 przez przeglądanie strony internetowej, czytanie wiadomości e-mail, odbieranie wiadomości SMS lub łączenie się z wrogą siecią. Na potrzeby naszych ocen dotkliwości uważamy również „bliższe” wektory ataków za zdalne. Należą do nich błędy, które może wykorzystać tylko osoba atakująca, która znajduje się fizycznie w pobliżu urządzenia docelowego, na przykład błąd, który wymaga wysyłania zniekształconych pakietów Wi-Fi lub Bluetooth. Ataki ultraszerokopasmowe (UWB) i NFC uważamy za proksymalne, a zatem zdalne.

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ą traktowane jako lokalne. Na potrzeby oceny ważności zespół ds. bezpieczeństwa systemu Android uważa również wektory ataków fizycznych za 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 w 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 podłączony, nie robi nic, aby zabezpieczyć pozostałe łącza w łańcuchu między urządzeniem a serwerami, z którymi się komunikuje.

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

Uwierzytelnianie biometryczne

Uwierzytelnianie biometryczne to trudna przestrzeń, a nawet najlepsze systemy mogą zostać oszukane przez prawie dopasowanie (zobacz Blog programistów Androida: Udoskonalenia ekranu blokady i uwierzytelniania w Androidzie 11 ). Te oceny dotkliwości rozróżniają dwie klasy ataków i mają na celu odzwierciedlenie rzeczywistego zagrożenia dla użytkownika końcowego.

Pierwsza klasa ataków pozwala na ominięcie uwierzytelniania biometrycznego w sposób uogólniony, bez wysokiej jakości danych biometrycznych od właściciela. Jeśli na przykład atakujący może umieścić gumę na czujniku odcisków palców i przyznać 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ływać 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 narzędzie ataku prezentacyjnego (podszywanie się) oparte na właścicielu urządzenia. Czasami te informacje biometryczne są stosunkowo łatwe do uzyskania (na przykład, jeśli czyjeś zdjęcie profilowe w mediach społecznościowych wystarcza do oszukania autoryzacji biometrycznej, obejście biometryczne otrzyma pełną ocenę ważnoś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 znacząca bariera, że ​​ogranicza liczbę osób dotkniętych atakiem, więc istnieje modyfikator -1 .

SYSTEM_ALERT_WINDOW i Tapjacking

Aby uzyskać informacje na temat naszych zasad dotyczących SYSTEM_ALERT_WINDOW i tapjackingu, zobacz sekcję " Tapjacking/overlay SYSTEM_ALERT_WINDOW na ekranie niekrytycznym dla bezpieczeństwa " na stronie BugHunter University z błędami bez wpływu na bezpieczeństwo .

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 składnik platformy Android, sterownik jądra dostarczony przez producenta oryginalnego sprzętu (OEM) lub jedna z wstępnie załadowanych aplikacji na urządzeniach 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 master AOSP; w przeciwnym razie są one najpierw naprawiane w naszych wewnętrznych repozytoriach.

Składnik jest również czynnikiem wpływającym na to, jak użytkownicy otrzymują aktualizacje. Błąd w strukturze lub jądrze wymaga aktualizacji oprogramowania układowego OTA, którą każdy producent OEM musi przepchnąć. Błąd w aplikacji lub bibliotece opublikowanej w Google Play (na przykład Gmail, Usługi Google Play lub WebView) można wysłać do użytkowników Androida jako aktualizację 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 dostarczymy poprawki. Lista wersji obsługiwanych przez backport zmienia się z każdą nową wersją Androida. Skontaktuj się z producentem urządzenia, aby uzyskać listę obsługiwanych urządzeń.

Wydanie 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 problemów o niskiej wadze można przesyłać bezpośrednio do gałęzi głównej AOSP, zanim poprawka będzie dostępna dla urządzeń za pośrednictwem OTA.

Otrzymuję aktualizacje Androida

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

Aktualizuję usługi Google

Oprócz dostarczania łatek na błędy w zabezpieczeniach, zespół ds. bezpieczeństwa systemu Android sprawdza 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ć błąd bezpieczeństwa. W przypadku aplikacji zainstalowanych spoza Google Play urządzenia z Usługami Google Play mogą również 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 o zabezpieczeniach 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.