Zespół ds. bezpieczeństwa Androida jest odpowiedzialny za zarządzanie lukami w zabezpieczeniach wykrytymi na platformie Android i wielu podstawowych aplikacjach na Androida dołączonych do urządzeń z Androidem.
Zespół ds. bezpieczeństwa Androida znajduje luki w zabezpieczeniach poprzez wewnętrzne badania, a także reaguje na błędy zgłaszane przez osoby trzecie. Źródła błędów zewnętrznych obejmują problemy zgłaszane za pośrednictwem formularza dotyczącego luk w zabezpieczeniach , opublikowane i wstępnie opublikowane badania akademickie, opiekunowie projektów open source, powiadomienia od naszych partnerów będących producentami urządzeń oraz publicznie ujawnione problemy opublikowane 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 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 lub rozwiązaniu problemu. Jeśli planujesz przesłać poprawkę lub test zestawu testów zgodności (CTS) w celu rozwiązania problemu z bezpieczeństwem, dołącz go do raportu o błędzie i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.
Selekcja błędów
Pierwszym zadaniem związanym z obsługą luki w zabezpieczeniach jest określenie wagi błędu i określenie, który składnik systemu Android jest dotknięty. Ważność określa priorytety problemu, a komponent określa, kto naprawi błąd, kto zostanie powiadomiony i w jaki sposób poprawka zostanie wdrożona dla użytkowników.
Typy kontekstów
Ta tabela zawiera definicje kontekstów bezpieczeństwa 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 uprzywilejowanych.
| Typ kontekstu | Definicja typu |
|---|---|
| Ograniczony kontekst | Ograniczone środowisko wykonawcze, w którym dostępne są tylko minimalne uprawnienia. Na przykład zaufane aplikacje przetwarzające niezaufane dane w środowisku piaskownicy. |
| Nieuprzywilejowany kontekst | Typowe środowisko wykonawcze oczekiwane przez nieuprzywilejowany kod. 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 wiele danych osobowych użytkownika 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ętu (THB) | Dyskretne komponenty sprzętowe, zwykle w SoC, które zapewniają funkcjonalność krytyczną dla podstawowych przypadków użycia urządzenia (takich jak komórkowe pasma podstawowe, DSP, GPU i procesory ML). |
| Łańcuch programu ładującego | Komponent, 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 hiperwizory, 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 oraz przed atakiem fizycznym, zgodnie z definicją we Wprowadzenie do bezpiecznych elementów . Obejmuje to układ Titan-M obecny w niektórych urządzeniach z Androidem. |
Powaga
Waga błędu generalnie odzwierciedla potencjalne szkody, które mogą wystąpić, jeśli błąd zostanie pomyślnie wykorzystany. Użyj następujących kryteriów, aby określić wagę.
| Ocena | Konsekwencje udanej eksploatacji |
|---|---|
| Krytyczny |
|
| Wysoki |
|
| Umiarkowany |
|
| Niski |
|
| Znikomy wpływ na bezpieczeństwo (NSI) |
|
Modyfikatory ocen
Podczas gdy powaga 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 kontekście uprzywilejowanym do przeprowadzenia ataku (nie dotyczy TEE, SE i hiperwizorów, takich jak pKVM) | -1 Poziom ciężkości |
| Szczegółowe informacje dotyczące luki w zabezpieczeniach ograniczają wpływ problemu | -1 Poziom ciężkości |
| Obejście uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia | -1 Poziom ciężkości |
| Konfiguracje kompilatora lub platformy ograniczają lukę w kodzie źródłowym | Umiarkowany poziom istotności, jeśli podstawowa luka w zabezpieczeniach 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 momentu włączenia | -1 Poziom ciężkości |
| 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 zgodnie z SEPolicy dostarczonymi przez Google | Znikomy wpływ na bezpieczeństwo |
Lokalny kontra proksymalny kontra zdalny
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 podczas przeglądania strony internetowej, czytania wiadomości e-mail, odbierania wiadomości SMS lub łączenia się z wrogą siecią. Na potrzeby naszych ocen dotkliwości uznajemy również „bliższe” wektory ataków za odległe. Należą do nich błędy, które może wykorzystać tylko atakujący, który 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. Ataki oparte na technologii ultraszerokopasmowej (UWB) i NFC uważamy za proksymalne, a zatem zdalne.
Lokalne ataki wymagają, aby ofiara uruchomiła aplikację, instalując ją i uruchamiając lub wyrażając zgodę na uruchomienie aplikacji błyskawicznej . Sparowane urządzenia towarzyszące będą traktowane jako lokalne. Na potrzeby oceny istotności zespół ds. bezpieczeństwa systemu Android bierze również pod uwagę wektory ataków fizycznych jako 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 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. Podczas gdy zabezpieczenia warstwy łącza (na przykład szyfrowanie Wi-Fi) zabezpieczają komunikację między urządzeniem a punktem dostępowym, z którym jest ono połączone, nie chronią pozostałych łączy w łańcuchu między urządzeniem a serwerami, z którymi się komunikuje.
Natomiast HTTPS zazwyczaj chroni całą komunikację od końca 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 protokole HTTPS/TLS: samo szyfrowanie Wi-Fi nie wystarcza do większości komunikacji w Internecie.
Uwierzytelnianie biometryczne
Uwierzytelnianie biometryczne to wymagająca przestrzeń, a nawet najlepsze systemy można oszukać przez zbliżenie (patrz Blog programistów Androida: Ekran blokady i ulepszenia uwierzytelniania w Androidzie 11 ). Te oceny istotności rozróżniają dwie klasy ataków i mają na celu odzwierciedlenie rzeczywistego ryzyka dla użytkownika końcowego.
Pierwsza klasa ataków pozwala na obejście uwierzytelniania biometrycznego w uogólniony sposób, bez wysokiej jakości danych biometrycznych od właściciela. Jeśli na przykład atakujący może umieścić kawałek gumy na czytniku linii papilarnych i 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 wiedzy właściciela urządzenia. Ze względu na to, ż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 blokady ekranu).
Inna klasa ataków zazwyczaj obejmuje narzędzie ataku polegające na prezentacji (fałszowanie) oparte na właścicielu urządzenia. Czasami uzyskanie tych informacji biometrycznych jest stosunkowo łatwe (na przykład, jeśli czyjeś zdjęcie profilowe w mediach społecznościowych wystarczy, aby oszukać autoryzację biometryczną, obejście biometryczne otrzyma pełną ocenę istotnoś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 istotna bariera, że ogranicza liczbę osób dotkniętych atakiem, więc istnieje modyfikator -1 .
SYSTEM_ALERT_WINDOW i przechwytywanie
Aby uzyskać informacje na temat naszych zasad dotyczących SYSTEM_ALERT_WINDOW i tapjackingu, zobacz sekcję „ Luka w zabezpieczeniach SYSTEM_ALERT_WINDOW Tapjacking/overlay na ekranie, który nie ma krytycznego znaczenia dla bezpieczeństwa ” na stronie BugHunter University poświęconej błędom bez wpływu na bezpieczeństwo .
Bezpieczeństwo wielu użytkowników w systemie operacyjnym Android Automotive
Android Automotive OS przyjmuje model bezpieczeństwa dla wielu użytkowników, który różni się od innych formatów. Każdy użytkownik Androida ma być używany przez inną osobę fizyczną. Na przykład tymczasowego użytkownika gościa można przypisać znajomemu, który pożycza pojazd od właściciela samochodu. Aby dostosować się do takich przypadków użycia, użytkownicy mają domyślnie dostęp do niezbędnych komponentów potrzebnych do korzystania z pojazdu, takich jak ustawienia Wi-Fi i sieci komórkowej.
Składnik, którego dotyczy problem
Zespół programistów odpowiedzialny za naprawienie błędu zależy od tego, w którym komponencie występuje błąd. Może to być główny składnik platformy Android, sterownik jądra dostarczony przez producenta oryginalnego sprzętu (OEM) lub jedna z fabrycznie załadowanych aplikacji na urządzenia 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 głównej AOSP; w przeciwnym razie są one najpierw naprawiane w naszych wewnętrznych repozytoriach.
Komponent jest również czynnikiem wpływającym na sposób, w jaki użytkownicy otrzymują aktualizacje. Błąd w architekturze lub jądrze wymaga aktualizacji oprogramowania sprzętowego OTA, którą musi przeprowadzić każdy producent OEM. 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 bezpieczeństwa Androida, powiadomimy partnerów Androida o szczegółach problemu i udostępnimy poprawki. Lista obsługiwanych wersji backportu zmienia się z każdą nową wersją Androida. Aby uzyskać listę obsługiwanych urządzeń, skontaktuj się z producentem urządzenia.
Zwolnienie 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 dotyczące problemów o niskiej wadze można przesyłać bezpośrednio do głównej gałęzi 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. Te aktualizacje mogą pochodzić od producenta OEM, który wyprodukował urządzenie, lub od operatora, który świadczy usługi serwisowe dla urządzenia. Aktualizacje urządzenia Google Pixel są dostarczane przez zespół Google Pixel po przejściu przez procedurę testowania akceptacji technicznej przez operatora. Google publikuje również obrazy fabryczne Pixela , które można załadować z boku na urządzenia.
Aktualizowanie usług Google
Oprócz dostarczania łatek usuwających błędy w zabezpieczeniach, zespół ds. bezpieczeństwa Androida przegląda 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ć lukę w zabezpieczeniach. W przypadku aplikacji zainstalowanych spoza Google Play urządzenia z usługami Google Play mogą również korzystać z funkcji weryfikacji aplikacji , aby ostrzegać użytkowników przed aplikacjami, 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 są dostępne w witrynach Android Open Source i Developer. Dobre miejsca na start:
- https://source.android.com/docs/security
- 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.
,Zespół ds. bezpieczeństwa Androida jest odpowiedzialny za zarządzanie lukami w zabezpieczeniach wykrytymi na platformie Android i wielu podstawowych aplikacjach na Androida dołączonych do urządzeń z Androidem.
Zespół ds. bezpieczeństwa Androida znajduje luki w zabezpieczeniach poprzez wewnętrzne badania, a także reaguje na błędy zgłaszane przez osoby trzecie. Źródła błędów zewnętrznych obejmują problemy zgłaszane za pośrednictwem formularza dotyczącego luk w zabezpieczeniach , opublikowane i wstępnie opublikowane badania akademickie, opiekunowie projektów open source, powiadomienia od naszych partnerów będących producentami urządzeń oraz publicznie ujawnione problemy opublikowane 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 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 lub rozwiązaniu problemu. Jeśli planujesz przesłać poprawkę lub test zestawu testów zgodności (CTS) w celu rozwiązania problemu z bezpieczeństwem, dołącz go do raportu o błędzie i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.
Selekcja błędów
Pierwszym zadaniem związanym z obsługą luki w zabezpieczeniach jest określenie wagi błędu i określenie, który składnik systemu Android jest dotknięty. Ważność określa priorytety problemu, a komponent określa, kto naprawi błąd, kto zostanie powiadomiony i w jaki sposób poprawka zostanie wdrożona dla użytkowników.
Typy kontekstów
Ta tabela zawiera definicje kontekstów bezpieczeństwa 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 uprzywilejowanych.
| Typ kontekstu | Definicja typu |
|---|---|
| Ograniczony kontekst | Ograniczone środowisko wykonawcze, w którym dostępne są tylko minimalne uprawnienia. Na przykład zaufane aplikacje przetwarzające niezaufane dane w środowisku piaskownicy. |
| Nieuprzywilejowany kontekst | Typowe środowisko wykonawcze oczekiwane przez nieuprzywilejowany kod. 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 wiele danych osobowych użytkownika 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ętu (THB) | Dyskretne komponenty sprzętowe, zwykle w SoC, które zapewniają funkcjonalność krytyczną dla podstawowych przypadków użycia urządzenia (takich jak komórkowe pasma podstawowe, DSP, GPU i procesory ML). |
| Łańcuch programu ładującego | Komponent, 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 hiperwizory, 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 oraz przed atakiem fizycznym, zgodnie z definicją we Wprowadzenie do bezpiecznych elementów . Obejmuje to układ Titan-M obecny w niektórych urządzeniach z Androidem. |
Powaga
Waga błędu generalnie odzwierciedla potencjalne szkody, które mogą wystąpić, jeśli błąd zostanie pomyślnie wykorzystany. Użyj następujących kryteriów, aby określić wagę.
| Ocena | Konsekwencje udanej eksploatacji |
|---|---|
| Krytyczny |
|
| Wysoki |
|
| Umiarkowany |
|
| Niski |
|
| Znikomy wpływ na bezpieczeństwo (NSI) |
|
Modyfikatory ocen
Podczas gdy powaga 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 kontekście uprzywilejowanym do przeprowadzenia ataku (nie dotyczy TEE, SE i hiperwizorów, takich jak pKVM) | -1 Poziom ciężkości |
| Szczegółowe informacje dotyczące luki w zabezpieczeniach ograniczają wpływ problemu | -1 Poziom ciężkości |
| Obejście uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia | -1 Poziom ciężkości |
| Konfiguracje kompilatora lub platformy ograniczają lukę w kodzie źródłowym | Umiarkowany poziom istotności, jeśli podstawowa luka w zabezpieczeniach 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 momentu włączenia | -1 Poziom ciężkości |
| 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 zgodnie z SEPolicy dostarczonymi przez Google | Znikomy wpływ na bezpieczeństwo |
Lokalny kontra proksymalny kontra zdalny
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 podczas przeglądania strony internetowej, czytania wiadomości e-mail, odbierania wiadomości SMS lub łączenia się z wrogą siecią. Na potrzeby naszych ocen dotkliwości uznajemy również „bliższe” wektory ataków za odległe. Należą do nich błędy, które może wykorzystać tylko atakujący, który 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. Ataki oparte na technologii ultraszerokopasmowej (UWB) i NFC uważamy za proksymalne, a zatem zdalne.
Lokalne ataki wymagają, aby ofiara uruchomiła aplikację, instalując ją i uruchamiając lub wyrażając zgodę na uruchomienie aplikacji błyskawicznej . Sparowane urządzenia towarzyszące będą traktowane jako lokalne. Na potrzeby oceny istotności zespół ds. bezpieczeństwa systemu Android bierze również pod uwagę wektory ataków fizycznych jako 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 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. Podczas gdy zabezpieczenia warstwy łącza (na przykład szyfrowanie Wi-Fi) zabezpieczają komunikację między urządzeniem a punktem dostępowym, z którym jest ono połączone, nie chronią pozostałych łączy w łańcuchu między urządzeniem a serwerami, z którymi się komunikuje.
Natomiast HTTPS zazwyczaj chroni całą komunikację od końca 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 protokole HTTPS/TLS: samo szyfrowanie Wi-Fi nie wystarcza do większości komunikacji w Internecie.
Uwierzytelnianie biometryczne
Uwierzytelnianie biometryczne to wymagająca przestrzeń, a nawet najlepsze systemy można oszukać przez zbliżenie (patrz Blog programistów Androida: Ekran blokady i ulepszenia uwierzytelniania w Androidzie 11 ). Te oceny istotności rozróżniają dwie klasy ataków i mają na celu odzwierciedlenie rzeczywistego ryzyka dla użytkownika końcowego.
Pierwsza klasa ataków pozwala na obejście uwierzytelniania biometrycznego w uogólniony sposób, bez wysokiej jakości danych biometrycznych od właściciela. Jeśli na przykład atakujący może umieścić kawałek gumy na czytniku linii papilarnych i 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 wiedzy właściciela urządzenia. Ze względu na to, ż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 blokady ekranu).
Inna klasa ataków zazwyczaj obejmuje narzędzie ataku polegające na prezentacji (fałszowanie) oparte na właścicielu urządzenia. Czasami uzyskanie tych informacji biometrycznych jest stosunkowo łatwe (na przykład, jeśli czyjeś zdjęcie profilowe w mediach społecznościowych wystarczy, aby oszukać autoryzację biometryczną, obejście biometryczne otrzyma pełną ocenę istotności). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.
SYSTEM_ALERT_WINDOW and Tapjacking
For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.
Multi-user security in Android Automotive OS
Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.
Affected component
The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.
Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.
The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.
Notifying partners
When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.
Releasing code to AOSP
If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.
Receiving Android updates
Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.
Updating Google services
In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.
Other resources
Information for Android app developers: https://developer.android.com
Security information exists throughout the Android Open Source and Developer sites. Good places to start:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Reports
Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.