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ą kwestie zgłaszane przez szablon Emisji Android Bezpieczeństwa , opublikowany i publikacja wstępna badań naukowych, przed projektem open source, opiekunów zgłoszeń od naszych partnerów producenta urządzenia i publicznie ujawnionych problemów zamieszczone na blogach i mediach społecznościowych.

Zgłaszanie problemów z bezpieczeństwem

Każdy programista, Android obsługi, albo badacz bezpieczeństwa może powiadomić Android zespół zabezpieczeń potencjalnych problemów bezpieczeństwa pośrednictwem formularza sprawozdawczego lukę w zabezpieczeniach .

Błędy oznaczone jako problemy z zabezpieczeniami nie są widoczne zewnętrznie, ale ostatecznie mogą być widoczne 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, którego składnika systemu Android dotyczy. Ważność określa priorytety 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 „piaskownice” aplikacji do przetwarzania niezaufanych danych bez zezwalania na dostęp do systemu bazowego.
Nieuprzywilejowany kontekst Typowe środowisko wykonawcze oczekiwane przez kod nieuprzywilejowany.

Na przykład, aplikacja na Androida, która działa w domenie SELinux z untrusted_app_all atrybutu.
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 Android z możliwościami, które byłyby zakazane przez SELinux untrusted_app domeny lub dostępu do privileged|signature uprawnień.
Zaufana baza obliczeniowa (TCB) Funkcjonalność, która jest częścią jądra, działa w tym samym kontekście procesora co jądro (takie jak sterowniki urządzeń), ma bezpośredni dostęp do pamięci jądra (takich jak komponenty sprzętowe na urządzeniu), ma możliwość ładowania skryptów do komponentu jądra ( na przykład eBPF), procesory komunikacyjne, lub jest jednym z nielicznych usług użytkownika, która jest uważana za odpowiednik jądra: apexd , bpfloader , init , ueventd i vold .
Łańcuch bootloadera Składnik, który konfiguruje urządzenie podczas rozruchu, a następnie przekazuje kontrolę do systemu operacyjnego Android.
Zaufane środowisko wykonywania (TEE) Komponent, który ma być chroniony nawet przed wrogim jądrem (na przykład TrustZone i Hypervisor).
Bezpieczna Enklawa / Bezpieczny Element (SE) Opcjonalny składnik sprzętowy przeznaczony do ochrony przed wszystkimi innymi składnikami na urządzeniu i przed atakiem fizycznym, jak określono w Wstęp zabezpieczyć Elements .

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

Powaga

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
  • Nieuprawniony dostęp do danych zabezpieczonych przez SE
  • Wykonanie dowolnego kodu w TEE lub SE
  • Zdalne wykonanie dowolnego kodu w uprzywilejowanym kontekście, łańcuchu bootloadera lub TCB
  • Zdalna, trwała odmowa usługi (stała lub wymagająca przeprogramowania całego systemu operacyjnego lub przywrócenia ustawień fabrycznych)
  • Zdalne omijanie wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub równoważnego zachowania
  • Zdalne omijanie wymagań dotyczących interakcji użytkownika dla dowolnych ustawień programisty, bezpieczeństwa lub prywatności
  • Zdalne obejście bezpiecznego rozruchu
  • Obejście mechanizmów 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 hasła do kont lub tokeny na okaziciela)
Wysoka
  • Lokalne obejście bezpiecznego rozruchu
  • Całkowite ominięcie podstawowej funkcji bezpieczeństwa (takiej jak SELinux, FDE lub seccomp)
  • Zdalne wykonanie dowolnego kodu w nieuprzywilejowanym kontekście
  • Lokalne wykonanie dowolnego kodu w uprzywilejowanym kontekście, łańcuchu bootloadera lub TCB
  • Nieuprawniony dostęp do danych zabezpieczonych przez TEE
  • Ataki na SE, które skutkują przejściem na mniej bezpieczną implementację
  • Lokalne obejście wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub równoważnego zachowania
  • Zdalny dostęp do chronionych danych (dane ograniczone do uprzywilejowanego kontekstu)
  • Lokalna, trwała odmowa usługi (stała lub wymagająca przeprogramowania całego systemu operacyjnego lub przywrócenia ustawień fabrycznych)
  • Zdalne 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)
  • Przesyłanie poufnych informacji przez niezabezpieczony protokół sieciowy (na przykład HTTP i nieszyfrowany Bluetooth), gdy osoba żądająca oczekuje bezpiecznej transmisji (zwróć uwagę, że nie dotyczy to szyfrowania Wi-Fi, takiego jak WEP)
  • 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 izolują od siebie dane aplikacji lub profile użytkowników
  • Lokalne omijanie wymagań dotyczących interakcji użytkownika dla dowolnych ustawień programisty, zabezpieczeń lub prywatności
  • Luka kryptograficzna umożliwiająca ataki na protokoły end-to-end, w tym ataki na zabezpieczenia warstwy transportowej (TLS) i Bluetooth (BT).
  • Obejście blokady
  • Obejście ochrony urządzenia/ochrona przywracania ustawień fabrycznych/ograniczenia operatora
  • Ukierunkowane zapobieganie dostępowi do służb ratowniczych
  • Obejście wymagań dotyczących interakcji użytkownika, które są zabezpieczane przez TEE
  • Zdalne zapobieganie dostępowi do usługi komórkowej bez interakcji użytkownika (na przykład awaria komórkowej usługi radiowej z powodu zniekształconego pakietu)
  • 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)
Umiarkowany
  • Zdalne wykonanie dowolnego kodu w ograniczonym kontekście
  • Zdalna tymczasowa odmowa usługi urządzenia (zdalne zawieszenie lub ponowne uruchomienie)
  • Lokalne wykonanie dowolnego kodu w nieuprzywilejowanym kontekście
  • Ogólne obejście w celu ochrony dogłębnej lub technologii łagodzenia zagrożeń w kontekście uprzywilejowanym lub TCB
  • Obejście ograniczeń w ograniczonym procesie
  • Zdalny dostęp do niezabezpieczonych danych (dane normalnie dostępne dla dowolnej lokalnie zainstalowanej aplikacji)
  • Lokalny dostęp do chronionych danych (dane ograniczone do uprzywilejowanego kontekstu)
  • 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)
  • Luka kryptograficzna w standardowych prymitywach kryptograficznych, która umożliwia wyciek zwykłego tekstu (nie prymitywów używanych w TLS)
  • Omijanie szyfrowania lub uwierzytelniania Wi-Fi
Niski
  • Lokalne wykonanie dowolnego kodu w ograniczonym kontekście
  • Luka kryptograficzna w niestandardowym użyciu
  • Ogólne obejście w celu dogłębnej ochrony na poziomie użytkownika lub wykorzystania technologii łagodzenia skutków w nieuprzywilejowanym kontekście
  • Nieprawidłowa dokumentacja, która może prowadzić do nieporozumień związanych z bezpieczeństwem z późniejszymi defektami kodu
  • Ogólne bypass personalizacji na urządzeniu dysponuje takimi jak Partner Voice lub twarzy Partner
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ć
  • Wszelkie luka, która wymaga nieprawidłowy system plików, jeśli system plików jest zawsze przyjęty / szyfrowane 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 jako uprzywilejowanego kontekstu do wykonania ataku -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 elementów wewnętrznych 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ą ofiary, aby uruchomić aplikację, albo przez zainstalowanie i uruchomienie aplikacji lub zgadzając się uruchomić dynamicznego App . Na potrzeby oceny ważności za lokalne uważamy również wektory ataków fizycznych. 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. Zwróć uwagę, że ataki wymagające połączenia USB mają taką samą wagę, niezależnie od tego, czy urządzenie ma być odblokowane, czy nie; często zdarza się, że urządzenia są odblokowywane po podłączeniu do 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

Autoryzacja biometryczna jest wyzwaniem przestrzeń, a nawet najlepsze systemy można nabrać przez bliskiej meczu (patrz Android Developers Blog: lockscreen i uwierzytelniania ulepszenia 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 blokady ekranu).

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ć więcej informacji na temat naszych zasad dotyczących SYSTEM_ALERT_WINDOW i tapjacking, patrz „Tapjacking / nakładki SYSTEM_ALERT_WINDOW podatności na nie-bezpieczeństwa-krytyczny ekran” części BugHunter Uczelni Błędy bez wpływu na bezpieczeństwo strony.

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 wypchnąć. 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 także wizerunki Pixel fabrycznych , które mogą być załadowane do boku urządzenia.

Aktualizuję usługi Google

Oprócz dostarczania poprawek do błędów bezpieczeństwa, 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. Dla aplikacji zainstalowanych spoza Google Play, urządzenia z luzem usługi Google mogą również skorzystać z weryfikowania aplikacji funkcji, aby ostrzec użytkowników o aplikacjach, które mogą być potencjalnie szkodliwe.

Inne zasoby

Informacje dla programistó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 zabezpieczeń dla więcej szczegółów.