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 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 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:
|
| 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 |
|
| Wysoki |
|
| Umiarkowany |
|
| Niski |
|
| Znikomy wpływ na bezpieczeństwo (NSI) |
|
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 poprawek do błędów 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ą 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:
- https://source.android.com/security/index
- https://developer.android.com/training/articles/security-tips
Raporty
Czasami zespół Android Security publikuje raporty lub oficjalne dokumenty. Zobacz Raporty bezpieczeństwa , aby uzyskać więcej informacji.