Zespół ds. bezpieczeństwa Androida jest odpowiedzialny za zarządzanie lukami w zabezpieczeniach wykrytymi na platformie Android i wielu podstawowych aplikacjach Androida dostarczanych z urządzeniami z Androidem.
Zespół ds. bezpieczeństwa Androida znajduje luki w zabezpieczeniach na podstawie wewnętrznych badań, a także reaguje na błędy zgłaszane przez strony trzecie. Źródła błędów zewnętrznych obejmują problemy zgłaszane za pośrednictwem formularza dotyczącego luk w zabezpieczeniach , opublikowane i wcześniej opublikowane badania akademickie, opiekunowie projektów open source, powiadomienia od naszych partnerów będących producentami urządzeń oraz publicznie ujawnione problemy publikowane na blogach i mediach społecznościowych.
Zgłaszanie problemów związanych z bezpieczeństwem
Każdy programista, użytkownik Androida lub badacz bezpieczeństwa może powiadomić zespół ds. bezpieczeństwa Androida o potencjalnych problemach związanych z bezpieczeństwem za pomocą formularza dotyczącego luk w zabezpieczeniach .
Błędy oznaczone jako problemy z bezpieczeństwem nie są widoczne z zewnątrz, ale mogą ostatecznie stać się widoczne po ocenie i rozwiązaniu problemu. Jeśli planujesz przesłać łatkę lub test pakietu testów zgodności (CTS) w celu rozwiązania problemu bezpieczeństwa, dołącz go do raportu o błędzie i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.
Wybieranie błędów
Pierwszym zadaniem w przypadku luki w zabezpieczeniach jest określenie wagi błędu i tego, którego składnika Androida dotyczy. Ważność określa priorytet problemu, a komponent określa, kto naprawia błąd, kto jest powiadamiany i w jaki sposób poprawka jest wdrażana wśród użytkowników.
Typy kontekstu
W tabeli tej przedstawiono definicje kontekstów zabezpieczeń sprzętu i oprogramowania. Kontekst można zdefiniować na podstawie wrażliwości danych, które zwykle przetwarza, lub obszaru, w którym działa. Nie wszystkie konteksty zabezpieczeń mają zastosowanie do wszystkich systemów. Ta tabela jest uporządkowana od najmniej do najbardziej uprzywilejowanego.
| Typ kontekstu | Definicja typu |
|---|---|
| Ograniczony kontekst | Środowisko o ograniczonym wykonywaniu, w którym zapewniane są tylko minimalne uprawnienia. Na przykład zaufane aplikacje przetwarzające niezaufane dane w środowisku piaskownicy. |
| Nieuprzywilejowany kontekst | Typowe środowisko wykonawcze oczekiwane przez kod nieuprzywilejowany. Na przykład aplikacja na Androida działająca w domenie SELinux z atrybutem untrusted_app_all . |
| Uprzywilejowany kontekst | Uprzywilejowane środowisko wykonawcze, które może mieć dostęp do podwyższonych uprawnień, obsługuje informacje umożliwiające identyfikację wielu użytkowników i/lub utrzymuje integralność systemu. Na przykład aplikacja na Androida z możliwościami, które byłyby zabronione przez domenę untrusted_app SELinux lub z dostępem do privileged|signature . |
| Jądro systemu operacyjnego | Funkcjonalność, która:
|
| Zaufana baza sprzętu (THB) | Dyskretne komponenty sprzętowe, zwykle w układzie SoC, które zapewniają funkcjonalność krytyczną dla podstawowych zastosowań urządzenia (takich jak komórkowe pasma podstawowe, procesory DSP, procesory graficzne i procesory ML). |
| Łańcuch bootloadera | Komponent, który konfiguruje urządzenie podczas uruchamiania, a następnie przekazuje kontrolę do systemu operacyjnego Android. |
| Zaufane środowisko wykonawcze (TEE) | Komponent zaprojektowany tak, aby był chroniony nawet przed wrogim jądrem systemu operacyjnego (na przykład TrustZone i hypervisory, takie jak pKVM, które chronią maszyny wirtualne przed jądrem systemu operacyjnego). |
| Bezpieczna enklawa / bezpieczny element (SE) | Opcjonalny komponent sprzętowy zaprojektowany w celu ochrony przed wszystkimi innymi komponentami urządzenia i przed atakiem fizycznym, zgodnie z definicją we wstępie do elementów bezpiecznych . Obejmuje to chip Titan-M obecny w niektórych urządzeniach z Androidem. |
Powaga
Waga błędu zazwyczaj odzwierciedla potencjalne szkody, które mogą wystąpić, jeśli błąd zostanie pomyślnie wykorzystany. Aby określić dotkliwość, użyj następujących kryteriów.
| Ocena | Konsekwencje udanej eksploatacji |
|---|---|
| Krytyczny |
|
| Wysoki |
|
| Umiarkowany |
|
| Niski |
|
| Znikomy wpływ na bezpieczeństwo (NSI) |
|
Modyfikatory ocen
Chociaż wagę luk w zabezpieczeniach często łatwo jest zidentyfikować, oceny mogą się zmieniać w zależności od okoliczności.
| Powód | Efekt |
|---|---|
| Aby wykonać atak, wymaga działania w kontekście uprzywilejowanym (nie dotyczy TEE, SE i hypervisorów, takich jak pKVM) | -1 Dotkliwość |
| Szczegóły dotyczące luki w zabezpieczeniach ograniczają wpływ problemu | -1 Dotkliwość |
| Obejście uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia | -1 Dotkliwość |
| Konfiguracje kompilatora lub platformy łagodzą lukę w kodzie źródłowym | Umiarkowana ważność, jeśli podstawowa luka jest umiarkowana lub wyższa |
| Wymaga fizycznego dostępu do elementów wewnętrznych urządzenia i jest nadal możliwy, jeśli urządzenie jest wyłączone lub nie zostało odblokowane od czasu włączenia | -1 Dotkliwość |
| Wymaga fizycznego dostępu do elementów wewnętrznych urządzenia, gdy jest ono włączone i zostało wcześniej odblokowane | -2 Dotkliwość |
| Lokalny atak wymagający odblokowania łańcucha bootloadera | Nie wyżej niż Niska |
| Lokalny atak wymagający włączonego trybu programisty lub jakichkolwiek trwałych ustawień trybu programisty na urządzeniu (i nie jest błędem w samym trybie programisty). | Nie wyżej niż Niska |
| Jeśli żadna domena SELinux nie może przeprowadzić operacji zgodnie z SEPolicy udostępnioną przez Google | Znikomy wpływ na bezpieczeństwo |
Lokalne kontra bliższe i odległe
Wektor ataku zdalnego wskazuje, że błąd można wykorzystać bez instalowania aplikacji lub bez fizycznego dostępu do urządzenia. Obejmuje to błędy, które mogą zostać wywołane przez przeglądanie strony internetowej, czytanie wiadomości e-mail, odbieranie wiadomości SMS lub łączenie się z wrogą siecią. Na potrzeby naszych ocen ważności „bliższe” wektory ataków uznajemy również za odległe. Należą do nich błędy, które może wykorzystać jedynie osoba atakująca, która fizycznie znajduje się w pobliżu urządzenia docelowego, na przykład błąd wymagający wysyłania zniekształconych pakietów Wi-Fi lub Bluetooth. Uważamy ataki ultraszerokopasmowe (UWB) i NFC za bliskie, a zatem odległe.
Ataki lokalne wymagają od ofiary uruchomienia aplikacji poprzez zainstalowanie i uruchomienie aplikacji lub wyrażenie zgody na uruchomienie aplikacji błyskawicznej . Sparowane urządzenia towarzyszące będą uznawane za lokalne. Na potrzeby oceny ważności zespół ds. bezpieczeństwa Androida uwzględnia również wektory ataków fizycznych jako lokalne. Należą do nich błędy, które może wykorzystać jedynie osoba atakująca mając fizyczny dostęp do urządzenia, na przykład błąd na ekranie blokady lub taki, który wymaga podłączenia kabla USB.
Bezpieczeństwo sieci
Android zakłada, że wszystkie sieci są wrogie i mogą przeprowadzać ataki lub szpiegować ruch. Chociaż zabezpieczenia warstwy łącza (na przykład szyfrowanie Wi-Fi) zabezpieczają komunikację między urządzeniem a punktem dostępu, do którego jest ono podłączone, nie zabezpieczają one w żaden sposób pozostałych łączy w łańcuchu między urządzeniem a serwerami, z którymi się komunikuje.
Z kolei protokół HTTPS zazwyczaj chroni całą komunikację od początku do końca, szyfrując dane u źródła, a następnie odszyfrowując je i weryfikując dopiero po dotarciu do miejsca docelowego. Z tego powodu luki zagrażające bezpieczeństwu sieci warstwy łącza są oceniane jako mniej poważne niż luki w zabezpieczeniach protokołu HTTPS/TLS: samo szyfrowanie Wi-Fi jest niewystarczające w przypadku większości komunikacji w Internecie.
Uwierzytelnianie biometryczne
Uwierzytelnianie biometryczne to trudna dziedzina i nawet najlepsze systemy mogą dać się oszukać przez prawie dopasowanie (zobacz blog Android Developers: Blokada ekranu i ulepszenia uwierzytelniania w Androidzie 11 ). Te wskaźniki ważności rozróżniają dwie klasy ataków i mają odzwierciedlać rzeczywiste ryzyko dla użytkownika końcowego.
Pierwsza klasa ataków pozwala w sposób uogólniony ominąć uwierzytelnianie biometryczne, bez uzyskania wysokiej jakości danych biometrycznych od właściciela. Jeśli na przykład osoba atakująca może umieścić kawałek gumy na czujniku odcisków palców, a on zapewnia dostęp do urządzenia na podstawie pozostałości pozostawionych na czujniku, jest to prosty atak, który można przeprowadzić na dowolnym podatnym urządzeniu. Nie wymaga żadnej wiedzy właściciela urządzenia. Biorąc pod uwagę, że można go uogólnić i potencjalnie wpłynąć na większą liczbę użytkowników, atak ten otrzymuje pełną ocenę ważności (na przykład Wysoka w przypadku obejścia ekranu blokady).
Druga klasa ataków zazwyczaj obejmuje instrument ataku prezentacyjnego (parodię) oparty na właścicielu urządzenia. Czasami uzyskanie takich informacji biometrycznych jest stosunkowo łatwe (na przykład, jeśli czyjeś zdjęcie profilowe w mediach społecznościowych wystarczy, aby oszukać uwierzytelnienie biometryczne, wówczas obejście biometryczne otrzyma pełną ocenę ważności). Jeśli jednak atakujący musiałby uzyskać dane biometryczne bezpośrednio od właściciela urządzenia (na przykład skan twarzy w podczerwieni), jest to na tyle znacząca bariera, że ogranicza liczbę osób dotkniętych atakiem, dlatego istnieje modyfikator -1 .
SYSTEM_ALERT_WINDOW i Tapjacking
Informacje na temat naszych zasad dotyczących SYSTEM_ALERT_WINDOW i tapjackingu można znaleźć w sekcji „ Luka w zabezpieczeniach SYSTEM_ALERT_WINDOW w zakresie Tapjacking/nakładka na ekranie niekrytycznym dla bezpieczeństwa ” na stronie BugHunter University Błędy bez wpływu na bezpieczeństwo .
Bezpieczeństwo wielu użytkowników w systemie operacyjnym Android Automotive
System operacyjny Android Automotive przyjmuje model bezpieczeństwa dla wielu użytkowników, inny niż w innych obudowach. Każdy użytkownik Androida jest przeznaczony do użytku przez inną osobę fizyczną. Na przykład tymczasowego gościa można przypisać znajomemu, który pożycza pojazd od właściciela samochodu. Aby uwzględnić takie przypadki użycia, użytkownicy domyślnie mają dostęp do niezbędnych komponentów potrzebnych do korzystania z pojazdu, takich jak ustawienia Wi-Fi i sieci komórkowej.
Dotknięty komponent
Zespół programistów odpowiedzialny za naprawienie błędu zależy od tego, w jakim komponencie występuje błąd. Może to być podstawowy komponent platformy Android, sterownik jądra dostarczony przez producenta oryginalnego sprzętu (OEM) lub jedna z aplikacji ładowanych fabrycznie na urządzeniach Pixel .
Błędy w kodzie AOSP są naprawiane przez zespół inżynierów Androida. Błędy o niskiej istotności, błędy w niektórych komponentach lub błędy, które są już publicznie znane, można naprawić bezpośrednio w publicznie dostępnej głównej gałęzi AOSP; w przeciwnym razie zostaną one najpierw naprawione w naszych wewnętrznych repozytoriach.
Komponent ma również wpływ na to, w jaki sposób użytkownicy otrzymują aktualizacje. Błąd w frameworku lub jądrze wymaga bezprzewodowej aktualizacji oprogramowania sprzętowego (OTA), którą każdy producent OEM musi przesłać. Błąd w aplikacji lub bibliotece opublikowanej w Google Play (na przykład Gmail, Usługi Google Play lub WebView) może zostać wysłany do użytkowników Androida jako aktualizacja z Google Play.
Powiadamianie partnerów
Gdy luka w zabezpieczeniach AOSP zostanie naprawiona w Biuletynie zabezpieczeń Androida, powiadomimy partnerów Androida o szczegółach problemu i udostępnimy poprawki. Lista wersji obsługiwanych przez backport zmienia się wraz z każdą nową wersją Androida. Skontaktuj się z producentem urządzenia, aby uzyskać listę obsługiwanych urządzeń.
Udostępnienie kodu do AOSP
Jeśli błąd bezpieczeństwa występuje w komponencie AOSP, poprawka jest przekazywana do AOSP po udostępnieniu użytkownikom wersji OTA. Poprawki dotyczące problemów o niskiej wadze można przesyłać bezpośrednio do głównego oddziału AOSP, zanim poprawka będzie dostępna dla urządzeń za pośrednictwem OTA.
Odbieranie aktualizacji Androida
Aktualizacje systemu Android są zazwyczaj dostarczane do urządzeń za pośrednictwem pakietów aktualizacji OTA. Aktualizacje te mogą pochodzić od producenta OEM, który wyprodukował urządzenie, lub od operatora świadczącego usługi serwisowe dla urządzenia. Aktualizacje urządzenia Google Pixel pochodzą od zespołu Google Pixel po przejściu procedury testów akceptacji technicznej u operatora. Google publikuje także obrazy fabryczne Pixela , które można wgrać z boku na urządzenia.
Aktualizowanie usług Google
Oprócz dostarczania poprawek na błędy bezpieczeństwa zespół ds. bezpieczeństwa Androida sprawdza błędy bezpieczeństwa, aby określić, czy istnieją inne sposoby ochrony użytkowników. Na przykład Google Play skanuje wszystkie aplikacje i usuwa każdą aplikację, która próbuje wykorzystać błąd bezpieczeństwa. W przypadku aplikacji zainstalowanych spoza Google Play urządzenia z Usługami Google Play mogą także korzystać z funkcji Weryfikuj aplikacje , aby ostrzegać użytkowników o aplikacjach, które mogą być potencjalnie szkodliwe.
Inne zasoby
Informacje dla twórców aplikacji na Androida: https://developer.android.com
Informacje dotyczące bezpieczeństwa znajdują się w witrynach Android Open Source i dla programistów. Dobre miejsca na początek:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Raporty
Czasami zespół ds. bezpieczeństwa Androida publikuje raporty lub oficjalne dokumenty. Więcej szczegółów znajdziesz w Raportach bezpieczeństwa .