Zasoby i aktualizacje dotyczące zabezpieczeń

Zespół ds. bezpieczeństwa Androida odpowiada za zarządzanie lukami w zabezpieczeniach, które zostały wykryte platformy Android i wielu podstawowych aplikacji dostępnych w pakiecie z urządzeniami z tym systemem.

Zespół ds. bezpieczeństwa Androida znajduje luki w zabezpieczeniach, przeprowadzając wewnętrzne badania. Reaguje na błędy zgłoszone przez osoby trzecie. Źródła błędów zewnętrznych obejmują problemy zgłoszone przez formularza pod kątem luk w zabezpieczeniach, opublikowanych i wcześniej opublikowanych badań akademickich, opiekunów projektów open source od naszych współpracujących producentów urządzeń oraz publicznie ujawnionych problemów opublikowanych w blogi i media społecznościowe.

Zgłaszanie problemów z bezpieczeństwem

Każdy programista, użytkownik Androida i badacz zabezpieczeń może powiadomić zespół ds. bezpieczeństwa Androida o potencjalnych problemów z bezpieczeństwem formularza luk w zabezpieczeniach.

Błędy oznaczone jako problemy z bezpieczeństwem nie są widoczne z zewnątrz, ale mogą się pojawić widoczne po sprawdzeniu lub rozwiązaniu problemu. Jeśli planujesz przesłać poprawkę lub Test zgodności z pakietem CTS (Compatibility Test Suite, który pozwala rozwiązać problem z zabezpieczeniami; dołącz do błędu) i poczekać na odpowiedź, zanim prześlesz kod do AOSP.

klasyfikowanie robaków,

Pierwszym zadaniem w rozwiązywaniu problemów z luką w zabezpieczeniach jest określenie wagi błędu którego komponentu Androida dotyczy problem. Określa ono wagę problemu, a komponent określa, kto naprawi błąd, kto zostanie powiadomiony i w jaki sposób zostanie wdrożona. użytkownikom.

Typy kontekstów

W tej tabeli znajdziesz definicje kontekstu zabezpieczeń sprzętu i oprogramowania. Kontekst może musi być definiowane wrażliwością danych, które zwykle przetwarza, lub obszarem, w którym są uruchamiane. Nie mają zastosowanie do wszystkich systemów. Tabela jest uporządkowana od najmniej do największej są chronione.

Typ kontekstu Definicja typu
Ograniczony kontekst Środowisko wykonawcze z ograniczonym dostępem, w którym tylko minimalna liczba uprawnień podany.

na przykład zaufane aplikacje przetwarzające niezaufane dane w piaskownicy. dla środowiska.
Kontekst bez uprawnień Typowe środowisko wykonawcze oczekiwane przez kod bez uprawnień.

Na przykład: aplikacja na Androida działająca w domenie SELinux z untrusted_app_all.
Kontekst z podwyższonymi uprawnieniami Środowisko wykonawcze z podwyższonymi uprawnieniami, które może mieć dostęp do podwyższonych uprawnień, uchwytów wielu informacji umożliwiających identyfikację użytkownika lub pozwala zachować integralność systemu.

Na przykład aplikacja na Androida z funkcjami, których zabraniałyby Domena SELinux untrusted_app lub dostęp do Uprawnienia: privileged|signature.
Jądro systemu operacyjnego Funkcje, które:
  • 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ść wczytywania skryptów do komponentu jądra (np. eBPF).
  • to jedna z nielicznych usług użytkownika uznawanych za równoważne jądra (na przykład apexd, bpfloader, init, ueventd, i vold).
Zaufany sprzęt (THB) Oddzielne komponenty sprzętowe (zwykle w układzie SOC), które zapewniają kluczowe działanie do podstawowych przypadków użycia urządzenia (takich jak komórkowe pasma podstawowe, procesory DSP, GPU czy systemy uczące się) procesory).
Łańcuch programu rozruchowego Komponent, który konfiguruje urządzenie podczas uruchamiania i przekazuje kontrolę do systemu operacyjnego Android.
Zaufane środowisko wykonawcze (TEE) Komponent zaprojektowany pod kątem ochrony przed wrogim jądrem systemu operacyjnego (np. TrustZone i hipernadzorcy (np. pKVM), które chronią maszyny wirtualne przed systemem operacyjnym. jądro).
Zabezpieczona enklawa / zabezpieczony element (SE) Opcjonalny komponent sprzętowy zaprojektowany w taki sposób, aby był chroniony przed wszystkimi innymi komponentami urządzenia i ataku fizycznego, zgodnie z definicją Wprowadzenie do bezpiecznych elementów.

Dotyczy to też układu Titan-M w niektórych urządzeniach z Androidem.

Poziom

Waga błędu zazwyczaj odzwierciedla potencjalne szkody, które mogą wystąpić, jeśli błąd został udało się wykorzystać. Użyj poniższych kryteriów, aby określić wagę.

Rating Konsekwencje udanego wykorzystania
Krytyczne
  • Wykonanie kodu dowolnego kodu w TEE lub SE
  • omijanie mechanizmów oprogramowania, które mają zapobiegać oprogramowaniu lub sprzętowi związanemu z bezpieczeństwem; podzespoły powstałe w wyniku awarii (np. zabezpieczenia termiczne).
  • zdalny dostęp do poufnych danych uwierzytelniających używanych do zdalnego uwierzytelniania usług (na takie jak hasła do kont czy tokeny okaziciela)
  • Zdalne wykonywanie dowolnego kodu w kontekście komórkowego pasma podstawowego bez użytkownika interakcje (na przykład wykorzystanie błędu w sieci komórkowej).
  • zdalne wykonywanie dowolnego kodu w kontekście z określonymi uprawnieniami, łańcuchu programu rozruchowego, THB lub jądro systemu operacyjnego
  • Zdalne omijanie wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub jego odpowiednika zachowanie
  • zdalne pomijanie wymagań dotyczących interakcji użytkownika z aplikacjami, które są przeznaczone dla programistów, ustawienia prywatności
  • Zdalna trwała odmowa usługi (trwała, wymagająca ponownego zainstalowania całego systemu operacyjnego lub ustawień fabrycznych).
  • Omijanie zdalnego uruchamiania bezpiecznego rozruchu
  • Nieupoważniony dostęp do danych zabezpieczonych przez mechanizm zabezpieczeń, w tym dostęp obsługiwany przez słabe klucze wsch.
Wysoki
  • Całkowite ominięcie głównej funkcji zabezpieczeń (na przykład SELinux, FBE lub seccomp).
  • ogólne ominięcie zabezpieczeń lub wykorzystanie technologii łagodzenia skutków problemu łańcuch programu rozruchowego, TEE lub SE
  • Ogólne omijanie zabezpieczeń systemu operacyjnego, które ujawniają pamięć lub zawartość plików między aplikacjami, użytkownikami i profilami
  • Ataki wymierzone w SE, które skutkują zmianą na mniej bezpieczną implementację
  • Przełącz się z zaatakowanego zdalnie oprogramowania typu bare metal (np. pasma podstawowego, CP/Communication Processor) do jądra procesora aplikacji (AP) lub go ominąć. mechanizmów służących do izolowania oprogramowania układowego bare metal od jądra AP
  • Omijanie ochrony urządzenia/ochrona przywracania do ustawień fabrycznych/ograniczenia operatora
  • Pominięcie wymagań dotyczących interakcji użytkownika zabezpieczonych przez TEE
  • luka w zabezpieczeniach kryptograficzna umożliwiająca ataki na kompleksowe protokoły w tym ataków na protokół TLS (Transport Layer Security) i Bluetooth (BT).
  • Dostęp lokalny do poufnych danych uwierzytelniających używanych do zdalnego uwierzytelniania usług (na takie jak hasła do kont czy tokeny okaziciela)
  • lokalne wykonanie dowolnego kodu w kontekście z podwyższonymi uprawnieniami, łańcuchem programu rozruchowego, THB lub jądro systemu operacyjnego
  • Omijanie lokalnego bezpiecznego rozruchu
  • Omijanie ekranu blokady
  • Lokalne obchodzenie wymagań dotyczących interakcji z użytkownikami w odniesieniu do głównych deweloperów, bezpieczeństwa i prywatności ustawienia
  • Lokalne obchodzenie wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub jego odpowiednika zachowanie
  • Trwała lokalna odmowa usługi (trwała, wymagająca ponownego zainstalowania całego systemu operacyjnego lub ustawień fabrycznych).
  • zdalny dostęp do chronionych danych (tzn. danych ograniczonych do kontekst)
  • Zdalne wykonywanie dowolnego kodu w kontekście bez uprawnień
  • zdalne blokowanie dostępu do sieci komórkowej lub Wi-Fi bez interakcji użytkownika (np. np. awaria sieci komórkowej z nieprawidłowym pakietem)
  • zdalne omijanie wymagań dotyczących interakcji użytkownika (dostęp do funkcji lub danych, które powinien wymagać zainicjowania przez użytkownika lub jego zgody)
  • Celowa blokada dostępu do służb ratunkowych
  • Przesyłanie informacji poufnych za pomocą niezabezpieczonego protokołu sieciowego (na przykład HTTP i nieszyfrowany Bluetooth), gdy żądający oczekuje bezpiecznej transmisji. Notatka że nie dotyczy to szyfrowania Wi-Fi (np. WEP)
  • Nieupoważniony dostęp do danych zabezpieczonych przez TEE, w tym dostęp obsługiwany przez słabe klucze w TEE
Umiarkowane
  • ogólne ominięcie zabezpieczeń lub wykorzystanie technologii łagodzenia skutków problemu kontekst z podwyższonymi uprawnieniami, THB lub jądro systemu operacyjnego
  • Ogólne omijanie zabezpieczeń systemu operacyjnego, które ujawnia stan procesu lub metadane obejmujące granice aplikacji, użytkownika lub profilu
  • Omijanie szyfrowania lub uwierzytelniania Wi-Fi
  • Kryptograficzne luki w zabezpieczeniach w standardowych prymitywach kryptograficznych, które umożliwiają wyciek tekst zwykły (nie elementy podstawowe używane w TLS)
  • lokalny dostęp do danych chronionych (tzn. do danych ograniczonych do kontekstu z podwyższonymi uprawnieniami);
  • Lokalne wykonywanie dowolnego kodu w kontekście bez uprawnień
  • Lokalne obejście wymagań dotyczących interakcji użytkownika (dostęp do funkcji lub danych, które zwykle wymagają zainicjowania przez użytkownika lub jego zgody)
  • zdalny dostęp do niechronionych danych (tzn. danych dostępnych lokalnie w dowolnym miejscu, zainstalowana aplikacja)
  • Zdalne wykonywanie dowolnego kodu w ograniczonym kontekście
  • Zdalna tymczasowa odmowa usługi na urządzeniu (zdalne zawieszenie lub ponowne uruchomienie)
Niskie
  • Ogólne omijanie zabezpieczeń na poziomie użytkownika lub wykorzystanie technologii ograniczania ryzyka w kontekst bez podwyższonych uprawnień
  • Pominięcie normalnego poziom ochrony uprawnienia
  • Luka kryptograficzna w niestandardowym wykorzystaniu
  • Ogólne pomijanie funkcji personalizacji na urządzeniu takich jak Voice Match lub Face Match
  • Niewłaściwa dokumentacja, która może zawierać lukę w zabezpieczeniach
  • Lokalne wykonywanie dowolnego kodu w ograniczonym kontekście
  • tekst zdefiniowany przez system zawierający wprowadzający w błąd opis, który powoduje utworzenie fałszywych informacji; oczekiwania dotyczące bezpieczeństwa
Nieistotny wpływ na bezpieczeństwo
  • Luka w zabezpieczeniach, której wpływ został zniwelowany przez co najmniej jeden modyfikator oceny lub architektura specyficzna dla wersji zmienia się tak, że efektywny poziom ważności jest niższy niż „Niski”, choć problem z kodem może pozostać
  • Luka w zabezpieczeniach wymagająca uszkodzonego systemu plików, jeśli jest on zawsze zastosowanych/zaszyfrowanych.
  • lokalna, tymczasowa odmowa usługi, na przykład gdy schorzenie można rozwiązać przez ponowne uruchomienie urządzenia lub odinstalowanie go; aplikacji aktywującej.

Modyfikatory ocen

Choć wagę luk w zabezpieczeniach jest często łatwa do zidentyfikowania, oceny mogą ulec zmianie w zależności od okoliczności.

Przyczyna Efekt
Wykonanie ataku wymaga uruchomienia w trybie uprzywilejowanym (nie dotyczy TEE, SE, i hipernadzorcy, np. pKVM) –1 poziom ważności
Szczegóły dotyczące luk w zabezpieczeniach ograniczają wpływ problemu –1 poziom ważności
Omijanie uwierzytelniania biometrycznego, które wymaga danych biometrycznych bezpośrednio z właściciel urządzenia – 1 poziom ważności
Konfiguracje kompilatora lub platformy eliminują luki w zabezpieczeniach w kodzie źródłowym Umiarkowana ważność, jeśli luka w zabezpieczeniach jest umiarkowana lub wyższa
Wymaga fizycznego dostępu do wewnętrznych elementów urządzenia i nadal jest możliwy, gdy urządzenie jest wyłączone lub nie zostało odblokowane od momentu włączenia –1 poziom ważności
Wymaga fizycznego dostępu do wewnętrznych elementów urządzenia, gdy urządzenie jest włączone i wcześniej było aktywne. zostało odblokowane – 2 stopień ważności
Lokalny atak, który wymaga odblokowania łańcucha programu rozruchowego Nie wyższa niż niska
Lokalny atak, który wymaga ustawień trybu programisty lub trwałych ustawień trybu programisty, być obecnie włączona na urządzeniu (nie jest to błąd w samym trybie programisty). Nie wyższa niż niska
Jeśli żadna domena SELinux nie może wykonać operacji w ramach udostępnionej przez Google zasady SEPolicy Znikomy wpływ na bezpieczeństwo

Lokalny a zbliżony a zdalny

Wektor ataku zdalnego oznacza, że błąd można wykorzystać bez instalowania aplikacji lub bez fizycznego dostępu do urządzenia. Obejmuje to także błędy, które mogą zostać aktywowane po przejściu do stronę internetową, przeczytać e-maila, otrzymać SMS-a lub połączyć się z wrogą siecią.

Zbliżone wektory ataku są uważane za odległe. Obejmują one błędy, które mogą być wykorzystywane wyłącznie przez osobę przeprowadzającą atak, która znajduje się fizycznie w pobliżu urządzenia docelowego (np. błąd, który wymaga wysyłanie nieprawidłowych pakietów Wi-Fi lub Bluetooth. Uwzględniamy łącza ultraszerokopasmowe (UWB) i NFC ma charakter zbliżony do siebie, a tym samym zdalnie.

Ataki lokalne wymagają, aby osoba przeprowadzająca atak miała wcześniej dostęp do ofiary. W hipotetycznej sytuacji może to być na przykład szkodliwa aplikacja zainstalowana przez ofiarę lub aplikację błyskawiczną, które mają wyrazić zgodę na uruchomienie.

Sparowane urządzenia (np. towarzyszące Bluetooth) są uznawane za urządzenia lokalne. Śr rozróżniania między sparowanym urządzeniem a urządzeniem, które jest używane w parowaniu. przepływu danych.

  • błędy, które utrudniają użytkownikowi identyfikację drugiego urządzenia (np. uwierzytelnianie) są uznawane za zbliżone, a tym samym zdalne.
  • Błędy, które pojawiają się podczas parowania, ale przed zgodą użytkownika (tj. autoryzacją) są uznawane za zbliżone, a więc odległe.
  • Błędy, które wystąpiły po uzyskaniu zgody użytkownika, są uznawane za lokalne, nawet jeśli parowanie się kończy.

Wektory ataku fizycznego są uważane za lokalne. Są to błędy, które mogą być wykorzystywane wyłącznie przez osoba przeprowadzająca atak, która ma fizyczny dostęp do urządzenia, np. błąd na ekranie blokady lub wymaga podłączenia kabla USB. Urządzenia są często odblokowywane, gdy podłączone do USB, ataki wymagające połączenia USB mają taką samą wagę niezależnie czy trzeba odblokować urządzenie.

Bezpieczeństwo sieci

Android zakłada, że wszystkie sieci są wrogie i mogą wstrzykiwać ataki lub szpiegować ruchu. Zabezpieczenia warstwy połączeń (np. szyfrowanie Wi-Fi) zabezpieczają komunikację między urządzeniem a punktem dostępu, z którym jest połączone, nie ma wpływu pozostałych połączeń w łańcuchu między urządzeniem a serwerami, z którymi urządzenie się komunikuje.

Z kolei protokół HTTPS zazwyczaj chroni całą komunikację w całości, szyfrując dane. u źródła, a następnie odszyfrować i zweryfikować go dopiero po osiągnięciu ostatecznego miejsca docelowego. Z tego powodu luki w zabezpieczeniach, które zagrażają bezpieczeństwu sieci warstwy linków, są rzadziej oceniane. poważne, niż w przypadku luk w zabezpieczeniach HTTPS/TLS: samo szyfrowanie Wi-Fi nie wystarcza komunikacji w internecie.

Uwierzytelnianie biometryczne

Uwierzytelnianie biometryczne nie jest łatwym zadaniem, dlatego nawet najlepsze systemy mogą dać się oszukać prawie dopasowane (zobacz blog dla deweloperów aplikacji na Androida: blokada ekranu i ulepszenia uwierzytelniania w Androidzie 11). Te oceny wagi rozróżniają 2 klasy ataków i mają na celu odzwierciedlają rzeczywiste ryzyko, jakie ponosi użytkownik.

Pierwsza klasa ataków pozwala na ominięcie uwierzytelniania biometrycznego w sposób ogólnikowy, bez wysokiej jakości danych biometrycznych właściciela. Jeśli na przykład osoba przeprowadzająca atak może umieścić kawałek gumy do żucia na czytniku linii papilarnych. Umożliwia on dostęp do urządzenia w zależności od pozostawiania na nim śladów jest to prosty atak, który można przeprowadzić na każdym podatnym urządzeniu. it nie wymaga żadnej wiedzy o właścicielu urządzenia. ponieważ jest to uniwersalne może mieć wpływ na większą liczbę użytkowników, atak ten otrzymuje pełną wagę (na przykład Wysoki w przypadku pomijania ekranu blokady).

Inna klasa ataków zwykle polega na wykorzystaniu instrumentu do przeprowadzenia ataku wykorzystującego prezentację (spow). na właściciela urządzenia. Czasami te dane biometryczne można łatwo uzyskać (na przykład Jeśli na przykład zdjęcie profilowe użytkownika w mediach społecznościowych jest wystarczające, by oszukać uwierzytelnianie biometryczne, wtedy funkcja ominięcia biometrycznego otrzyma pełną wagę). Jeśli jednak osoba przeprowadzająca atak musiałaby pozyskiwania danych biometrycznych bezpośrednio od właściciela urządzenia (np. skanowanie w podczerwieni na twarz), to na tyle poważna bariera, że zmniejsza liczbę osób, więc mamy modyfikator -1.

SYSTEM_ALERT_WINDOW i tapjacking

Informacje o naszych zasadach dotyczących SYSTEM_ALERT_WINDOW i tapjackingu znajdziesz tutaj: Zobacz „lukę w zabezpieczeniach do kliknięcia/nakładki SYSTEM_ALERT_WINDOW na ekranie niekrytycznym” na Uniwersytecie BugHunter Błędy bez wpływu na bezpieczeństwo stronę.

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

System operacyjny Android Automotive wykorzystuje model zabezpieczeń dla wielu użytkowników różnią się od innych formatów. Każdego użytkownika Androida powinien używać inny osobę fizyczną. Na przykład tymczasowy gość może zostać przypisany do znajomego, który pożycza samochodu należącego do właściciela. Aby uwzględnić takie przypadki użycia, domyślnie użytkownicy mają dostęp do niezbędnych elementów niezbędnych do korzystania z pojazdu, takich jak Wi-Fi czy sieć komórkowa. ustawieniach.

Komponent, którego dotyczy problem

Zespół programistów odpowiedzialny za naprawę błędu zależy od tego, którego komponentu zawiera błąd. Może to być podstawowy komponent platformy Androida – sterownika jądra dostarczanego przez producenta sprzętu (OEM) lub jednej z wstępnie załadowanych aplikacji na urządzenia Pixel.

Błędy w kodzie AOSP są naprawiane przez zespół inżynierów Androida. Mała waga błędów, robaki określone komponenty lub błędy, które są już znane publicznie, można naprawić bezpośrednio publicznie dostępna oddział główny AOSP; w przeciwnym razie są naprawione w naszych wewnętrznych repozytoriach. .

Komponent wpływa też na sposób pobierania aktualizacji przez użytkowników. błąd platformy lub jądra systemu, wymaga bezprzewodowej aktualizacji oprogramowania układowego, którą musi przeprowadzić każdy OEM. błąd w aplikacji lub biblioteka opublikowana w Google Play (np. Gmail, Usługi Google Play czy WebView) może zostać wysyłanej do użytkowników Androida w ramach aktualizacji z Google Play.

Powiadamianie partnerów

O usunięciu luki w zabezpieczeniach AOSP w biuletynie na temat bezpieczeństwa Androida poinformujemy, partnerów Androida z informacjami o problemach i udostępnia poprawki. Lista wersji obsługiwanych przez backend z każdą nową wersją Androida. Aby uzyskać listę urządzeń, skontaktuj się z producentem urządzenia obsługiwanych urządzeniach.

Zwalniam kod AOSP

Jeśli błąd związany z bezpieczeństwem znajduje się w komponencie AOSP, poprawka jest przekazywana do AOSP po zaktualizowaniu OTA i udostępniać je użytkownikom. Poprawki o małej wadze można przesyłać bezpośrednio do głównej agencji AOSP przed udostępnieniem poprawki urządzeń przy użyciu funkcji OTA.

Otrzymuję aktualizacje Androida

Aktualizacje systemu Android są zazwyczaj instalowane na urządzeniach za pomocą pakietów aktualizacji OTA. Mogą one pochodzić od producenta OEM, który wyprodukował urządzenie, lub od przewoźnika, usłudze. Aktualizacje urządzeń Google Pixel pochodzą od zespołu Google Pixel w ramach procedury testowania w ramach akceptacji technicznej operatora. Google publikuje też fabryczne obrazy telefonu Pixel, które mogą być przesłane z innego źródła do urządzeń.

Aktualizuję usługi Google

Zespół ds. bezpieczeństwa Androida nie tylko instaluje poprawki błędów, ale też sprawdza zabezpieczenia. aby określić, czy istnieją inne sposoby ochrony użytkowników. Na przykład Google Play skanuje wszystkie aplikacji i usuwa wszystkie aplikacje, które próbują wykorzystać błąd w zabezpieczeniach. W przypadku aplikacji zainstalowanych z poza Google Play na urządzeniach z Usługami Google Play mogą też być używane Weryfikacja aplikacji, po której pojawi się ostrzeżenie użytkowników o potencjalnie szkodliwych aplikacjach.

Inne materiały

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

Informacje o zabezpieczeniach są dostępne w witrynach open source Androida i witrynach dla deweloperów. Dobra miejsca początkowe:

Raporty

Czasami zespół ds. bezpieczeństwa Androida publikuje raporty lub raporty. Zobacz Raporty zabezpieczeń