Aktualizacje i materiały dotyczące zabezpieczeń

Zespół ds. bezpieczeństwa Androida odpowiada 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 wykrywa luki w zabezpieczeniach w ramach wewnętrznych badań, a także reaguje na błędy zgłaszane przez osoby trzecie. Źródła błędów zewnętrznych to m.in. problemy zgłaszane za pomocą formularza zgłaszania luk w zabezpieczeniach, opublikowane i nieopublikowane badania naukowe, osoby zarządzające projektami open source, powiadomienia od naszych partnerów – producentów urządzeń oraz publicznie ujawnione problemy opublikowane na blogach lub w mediach społecznościowych.

Zgłaszanie problemów dotyczących bezpieczeństwa

Każdy deweloper, użytkownik Androida lub badacz ds. bezpieczeństwa może powiadomić zespół ds. bezpieczeństwa Androida o potencjalnych problemach z bezpieczeństwem za pomocą formularza zgłaszania luk w zabezpieczeniach.

Błędy oznaczone jako problemy z zabezpieczeniami nie są widoczne na zewnątrz, ale po ich ocenie lub rozwiązaniu mogą zostać udostępnione. Jeśli planujesz przesłać poprawkę lub test pakietu testów zgodności (CTS), aby rozwiązać problem z bezpieczeństwem, załącz ją do raportu o błędzie i poczekaj na odpowiedź, zanim prześlesz kod do AOSP.

Grupowanie błędów

Pierwszym krokiem w reagowaniu na lukę w zabezpieczeniach jest określenie wagi błędu i tego, którego komponentu Androida dotyczy. Waga określa priorytet problemu, a komponent decyduje o tym, kto naprawi błąd, kto otrzyma powiadomienie i w jaki sposób poprawka zostanie wdrożona u użytkowników.

Typy kontekstu

Ta tabela zawiera definicje kontekstów bezpieczeństwa sprzętu i oprogramowania. Kontekst może być określony przez wrażliwość danych, które zwykle przetwarza, lub obszar, w którym działa. Nie wszystkie konteksty bezpieczeństwa mają zastosowanie do wszystkich systemów. Tabela jest posortowana od najmniej do najbardziej uprzywilejowanych.

Typ kontekstu Definicja typu
Ograniczony kontekst Ograniczone środowisko wykonawcze, w którym przyznawane są tylko najbardziej podstawowe uprawnienia.

Na przykład zaufane aplikacje przetwarzające niezaufane dane w środowisku piaskownicy.
Kontekst bez podwyższonych uprawnień Typowe środowisko wykonawcze oczekiwane przez kod bez uprawnień.

Na przykład aplikacja na Androida, która działa w domenie SELinux z atrybutem untrusted_app_all.
Kontekst z podwyższonymi uprawnieniami Uprzywilejowane środowisko wykonawcze, które może mieć dostęp do rozszerzonych uprawnień, obsługiwać dane osobowe wielu użytkowników lub utrzymywać integralność systemu.

Na przykład aplikacja na Androida z funkcjami, które byłyby zabronione przez domenę SELinux untrusted_app lub z dostępem do privileged|signature uprawnień.
jądro systemu operacyjnego, Funkcje, które:
  • jest częścią jądra,
  • działa w tym samym kontekście procesora co jądro (np. sterowniki urządzeń);
  • ma bezpośredni dostęp do pamięci jądra (np. komponenty sprzętowe na urządzeniu);
  • ma możliwość wczytywania skryptów do komponentu jądra (np. eBPF);
  • jest jedną z kilku usług użytkownika, które są uważane za odpowiedniki jądra (np. apexd, bpfloader, init, ueventd i vold).
Trusted Hardware Base (THB) Oddzielne komponenty sprzętowe, zwykle na układzie SoC, które zapewniają funkcje kluczowe dla podstawowych zastosowań urządzenia (takie jak pasma podstawowe sieci komórkowej, procesory DSP, GPU i ML).
Łańcuch programu rozruchowego Komponent, który konfiguruje urządzenie podczas uruchamiania, 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 (np. TrustZone i hipernadzorcy, tacy jak pKVM, którzy chronią maszyny wirtualne przed jądrem systemu operacyjnego).
Secure Enclave / Secure Element (SE) Opcjonalny komponent sprzętowy zaprojektowany tak, aby był chroniony przed wszystkimi innymi komponentami urządzenia i przed atakami fizycznymi, zgodnie z definicją w tym artykule.

Obejmuje to układ Titan-M, który jest dostępny na niektórych urządzeniach z Androidem.

Poziom

Poziom ważności błędu odzwierciedla potencjalne szkody, które mogą wystąpić, jeśli błąd zostanie wykorzystany. Aby określić poziom ważności, użyj tych kryteriów.

Rating Skutki udanego wykorzystania
Krytyczne
  • Wykonywanie dowolnego kodu w zaufanym środowisku wykonawczym lub bezpiecznym elemencie
  • Omijanie mechanizmów oprogramowania zaprojektowanych w celu zapobiegania nieprawidłowemu działaniu oprogramowania lub sprzętu związanego z bezpieczeństwem (np. zabezpieczeń termicznych).
  • zdalny dostęp do poufnych danych logowania używanych do uwierzytelniania usług zdalnych (np. haseł do kont lub tokenów dostępu);
  • Zdalne wykonywanie dowolnego kodu w kontekście pasma podstawowego sieci komórkowej bez interakcji użytkownika (np. wykorzystanie błędu w usłudze radia komórkowego).
  • Zdalne wykonanie dowolnego kodu w kontekście uprzywilejowanym, w łańcuchu programu rozruchowego, THB lub jądrze systemu operacyjnego.
  • Zdalne obejście wymagań dotyczących interakcji użytkownika podczas instalowania pakietu lub podobne zachowanie
  • Zdalne omijanie wymagań dotyczących interakcji użytkownika w przypadku podstawowych ustawień dewelopera, zabezpieczeń lub prywatności
  • Zdalny trwały atak typu DoS (trwały, wymagający ponownego wgrania całego systemu operacyjnego lub przywrócenia ustawień fabrycznych)
  • Zdalne obejście bezpiecznego rozruchu
  • Nieautoryzowany dostęp do danych zabezpieczonych przez SE, w tym dostęp umożliwiony przez słabe klucze w SE.
Wysoki
  • całkowite obejście podstawowej funkcji zabezpieczeń (np. SELinux, FBE lub seccomp);
  • Ogólne obejście ochrony warstwowej lub technologii ograniczającej wykorzystanie luk w zabezpieczeniach w łańcuchu programu rozruchowego, TEE lub SE.
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które ujawnia zawartość pamięci lub plików w różnych aplikacjach, użytkownikach lub profilach.
  • ataki na SE, które powodują obniżenie poziomu bezpieczeństwa do mniej bezpiecznej implementacji;
  • Przejście z oprogramowania układowego naruszonego urządzenia fizycznego, do którego można uzyskać zdalny dostęp (np. pasmo podstawowe, procesor komunikacyjny), do jądra systemu (operacyjnego) procesora aplikacji lub obejście mechanizmów zaprojektowanych w celu odizolowania oprogramowania układowego urządzenia fizycznego od jądra systemu (operacyjnego) procesora aplikacji.
  • Obejście ochrony urządzenia, ochrony przed przywróceniem do ustawień fabrycznych (w Androidzie 15 i nowszych) lub ograniczeń operatora
  • Omijanie wymagań dotyczących interakcji użytkownika, które są zabezpieczone przez TEE
  • Luka kryptograficzna, która umożliwia ataki na protokoły typu end-to-end, w tym ataki na protokoły TLS (Transport Layer Security) i Bluetooth (BT).
  • lokalny dostęp do danych logowania używanych do uwierzytelniania usług zdalnych (np. haseł do kont lub tokenów dostępu);
  • Lokalne wykonanie dowolnego kodu w kontekście uprzywilejowanym, łańcuch programu rozruchowego, THB lub jądro systemu operacyjnego
  • Lokalne obejście bezpiecznego rozruchu
  • Omijanie ekranu blokady
  • Lokalne ominięcie wymagań dotyczących interakcji użytkownika w przypadku podstawowych ustawień dla programistów, bezpieczeństwa lub prywatności
  • Lokalne pomijanie wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub podobnego działania
  • Lokalny trwały atak typu DoS (wymagający ponownego wgrania całego systemu operacyjnego lub przywrócenia do ustawień fabrycznych)
  • zdalny dostęp do danych chronionych (czyli danych, do których dostęp jest ograniczony do uprzywilejowanego kontekstu);
  • Zdalne wykonanie dowolnego kodu w kontekście bez uprawnień
  • Zdalne ataki typu DoS w przypadku usług komórkowych lub Wi-Fi, które utrzymują się do momentu interwencji użytkownika, wywoływane bez interakcji użytkownika (np. awaria usługi radiowej komórkowej z powodu nieprawidłowo sformułowanego pakietu, która nie jest automatycznie przywracana i wymaga ręcznego ponownego uruchomienia lub ponownego uruchomienia urządzenia).
  • Zdalne obejście wymagań dotyczących interakcji z użytkownikiem (dostęp do funkcji lub danych, które powinny wymagać inicjacji przez użytkownika lub zgody użytkownika).
  • Ukierunkowane blokowanie dostępu do służb ratunkowych
  • przesyłanie informacji poufnych za pomocą niezabezpieczonego protokołu sieciowego (np. HTTP i nieszyfrowanego Bluetootha), gdy osoba wysyłająca żądanie oczekuje bezpiecznej transmisji; Uwaga: nie dotyczy to szyfrowania Wi-Fi (np. WEP).
  • Nieautoryzowany dostęp do danych zabezpieczonych przez TEE, w tym dostęp umożliwiony przez słabe klucze w TEE
Umiarkowane
  • Ogólne obejście zabezpieczeń w ramach strategii obrony w głąb lub technologii ograniczających wykorzystywanie luk w kontekście z podwyższonymi uprawnieniami, THB lub jądra systemu operacyjnego
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które ujawnia stan procesu lub metadane między aplikacjami, użytkownikami lub profilami.
  • Omijanie szyfrowania lub uwierzytelniania Wi-Fi
  • Luka kryptograficzna w standardowych prymitywach kryptograficznych, która umożliwia wyciek tekstu jawnego (nie dotyczy prymitywów używanych w TLS).
  • lokalny dostęp do danych chronionych (czyli danych, które są ograniczone do kontekstu uprzywilejowanego);
  • 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 normalnie wymagałyby działania użytkownika lub jego zgody)
  • zdalny dostęp do niechronionych danych (czyli danych, do których zwykle ma dostęp każda aplikacja zainstalowana lokalnie);
  • Zdalne wykonanie dowolnego kodu w ograniczonym kontekście
  • Zdalna tymczasowa blokada usługi na urządzeniu (zdalne zawieszenie lub ponowne uruchomienie)
Niski
  • Ogólne obejście wielopoziomowej obrony w głąb na poziomie użytkownika lub technologii ograniczającej wykorzystywanie luk w zabezpieczeniach w kontekście bez uprawnień.
  • Ominięcie normalnego poziomu ochrony uprawnień
  • Luka kryptograficzna w niestandardowym użyciu
  • Ogólne pomijanie funkcji personalizacji na urządzeniu, takich jak Voice Match czy Face Match.
  • Nieprawidłowa dokumentacja, która może prowadzić do luki w zabezpieczeniach
  • Lokalne wykonywanie dowolnego kodu w ograniczonym kontekście
  • Tekst zdefiniowany przez system, który zawiera wprowadzający w błąd opis, który stwarza fałszywe oczekiwania dotyczące bezpieczeństwa.
Znikomy wpływ na bezpieczeństwo (NSI)
  • Luka w zabezpieczeniach, której wpływ został ograniczony przez co najmniej 1 modyfikator oceny lub zmiany w architekturze specyficzne dla wersji, tak że rzeczywista ważność jest niższa niż niska, chociaż podstawowy problem z kodem może nadal występować.
  • Wszelkie luki w zabezpieczeniach, które wymagają nieprawidłowo sformatowanego systemu plików, jeśli ten system plików jest zawsze przyjmowany/szyfrowany przed użyciem.
  • Lokalny tymczasowy atak typu DoS, np. w przypadku gdy problem można rozwiązać, ponownie uruchamiając urządzenie lub odinstalowując aplikację, która go spowodowała.

Modyfikatory poziomu ważności

Chociaż w wielu przypadkach łatwo jest określić wagę luk w zabezpieczeniach, oceny mogą się zmieniać w zależności od okoliczności.

Przyczyna Efekt
Wymaga uruchomienia w kontekście uprzywilejowanym, aby przeprowadzić atak (nie dotyczy TEE, SE i hiperwizorów, takich jak pKVM). Poziom ważności -1
Szczegóły dotyczące luki w zabezpieczeniach ograniczają wpływ problemu Poziom ważności -1
obejście uwierzytelniania biometrycznego, które wymaga informacji biometrycznych bezpośrednio od właściciela urządzenia; Poziom ważności -1
Konfiguracje kompilatora lub platformy łagodzą skutki luki w zabezpieczeniach w kodzie źródłowym. Umiarkowana waga, jeśli podstawowa luka w zabezpieczeniach ma wagę Umiarkowaną lub wyższą.
Wymaga fizycznego dostępu do wnętrza urządzenia i jest możliwy nawet wtedy, gdy urządzenie jest wyłączone lub nie zostało odblokowane od momentu włączenia. Poziom ważności -1
Wymaga fizycznego dostępu do wnętrza urządzenia, gdy jest ono włączone i wcześniej odblokowane. Poziom ważności 2
atak lokalny, który wymaga odblokowania łańcucha programu rozruchowego; Nie wyższa niż niska
Lokalny atak, który wymaga włączenia na urządzeniu trybu programisty lub dowolnych trwałych ustawień trybu programisty (i nie jest błędem w samym trybie programisty). Nie wyższa niż niska
Jeśli żadna domena SELinux nie może przeprowadzić operacji w ramach zasad SEPolicy dostarczonych przez Google. Zaniedbywalny wpływ na bezpieczeństwo

Lokalne, bliskie i zdalne

Zdalny wektor ataku oznacza, że błąd można wykorzystać bez instalowania aplikacji lub bez fizycznego dostępu do urządzenia. Obejmuje to błędy, które mogą być wywoływane przez przeglądanie strony internetowej, czytanie e-maili, odbieranie SMS-ów lub łączenie się z wrogą siecią.

Wektory ataku w pobliżu są traktowane jako zdalne. Obejmują one błędy, które mogą być wykorzystywane tylko przez atakującego znajdującego się w pobliżu urządzenia docelowego, np. błąd wymagający wysłania nieprawidłowo sformatowanych pakietów Wi-Fi lub Bluetooth. Ataki wykorzystujące łącze ultraszerokopasmowe (UWB) i technologię NFC uważamy za ataki z bliskiej odległości, a tym samym za ataki zdalne.

Ataki lokalne wymagają od atakującego wcześniejszego dostępu do ofiary. W hipotetycznym przykładzie dotyczącym wyłącznie oprogramowania może to być złośliwa aplikacja zainstalowana przez ofiarę lub aplikacja błyskawiczna, na której uruchomienie ofiara wyraziła zgodę.

Sparowane urządzenia (np. urządzenia towarzyszące Bluetooth) są traktowane jako lokalne. Rozróżniamy sparowane urządzenie i urządzenie, które uczestniczy w procesie parowania.

  • Błędy, które pogarszają możliwość zidentyfikowania przez użytkownika innego urządzenia, z którym jest parowane urządzenie (np. uwierzytelnianie), są uważane za bliskie, a tym samym zdalne.
  • Błędy, które występują podczas procesu parowania, ale przed uzyskaniem zgody użytkownika (czyli autoryzacji), są uważane za bliskie, a tym samym za zdalne.
  • Błędy, które występują po uzyskaniu zgody użytkownika, są uważane za lokalne, nawet jeśli parowanie ostatecznie się nie powiedzie.

Wektory ataków fizycznych są uważane za lokalne. Obejmują one błędy, które mogą być wykorzystane tylko przez atakującego, który ma fizyczny dostęp do urządzenia, np. błąd na ekranie blokady lub błąd, który wymaga podłączenia kabla USB. Urządzenia są często odblokowywane po podłączeniu do USB, więc ataki wymagające połączenia USB mają taką samą wagę niezależnie od tego, czy urządzenie musi być odblokowane.

Bezpieczeństwo sieciowe

Android zakłada, że wszystkie sieci są wrogie i mogą być wykorzystywane do przeprowadzania ataków lub szpiegowania ruchu. Zabezpieczenia warstwy łącza (np. szyfrowanie Wi-Fi) chronią komunikację między urządzeniem a punktem dostępu, z którym jest ono połączone, ale nie zabezpieczają pozostałych połączeń w łańcuchu między urządzeniem a serwerami, z którymi się ono komunikuje.

Z kolei protokół HTTPS zwykle chroni całą komunikację od początku do końca, szyfrując dane u źródła, a następnie odszyfrowując i weryfikując je dopiero po dotarciu do miejsca docelowego. Z tego powodu luki w zabezpieczeniach sieci warstwy łącza są oceniane jako mniej poważne niż luki w zabezpieczeniach HTTPS/TLS: samo szyfrowanie Wi-Fi jest niewystarczające w przypadku większości komunikacji w internecie.

uwierzytelniania biometrycznego.

Uwierzytelnianie biometryczne jest trudną dziedziną, a nawet najlepsze systemy można oszukać, używając podobnego odcisku palca (patrz blog dla deweloperów aplikacji na Androida: ulepszenia ekranu blokady i uwierzytelniania w Androidzie 11). Te oceny ważności rozróżniają 2 rodzaje ataków i mają odzwierciedlać rzeczywiste ryzyko dla użytkownika.

Pierwsza grupa ataków umożliwia obejście uwierzytelniania biometrycznego w sposób ogólny, bez wysokiej jakości danych biometrycznych właściciela. Jeśli na przykład osoba przeprowadzająca atak może umieścić gumę do żucia na czytniku linii papilarnych, a urządzenie przyzna dostęp na podstawie pozostałości na czytniku, będzie to prosty atak, który można przeprowadzić na każdym podatnym urządzeniu. Nie wymaga to żadnej wiedzy o właścicielu urządzenia. Biorąc pod uwagę, że jest on uogólniony i może dotyczyć większej liczby użytkowników, ten atak otrzymuje pełną ocenę ważności (np. wysoka w przypadku obejścia blokady ekranu).

Druga klasa ataków zwykle obejmuje instrument do ataku przez prezentację (fałszerstwo) oparty na właścicielu urządzenia. Czasami te informacje biometryczne są stosunkowo łatwe do uzyskania (np. jeśli zdjęcie profilowe w mediach społecznościowych wystarczy, aby oszukać uwierzytelnianie biometryczne, 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 (np. skanowanie twarzy w podczerwieni), stanowi to wystarczającą barierę, która ogranicza liczbę osób dotkniętych atakiem, więc stosujemy modyfikator -1.

SYSTEM_ALERT_WINDOW i tapjacking

Informacje o naszych zasadach dotyczących SYSTEM_ALERT_WINDOW i tapjackingu znajdziesz w sekcji „Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen” na stronie Błędy bez wpływu na bezpieczeństwo w BugHunter University.

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

System operacyjny Android Automotive wykorzystuje model zabezpieczeń dla wielu użytkowników, który różni się od modeli stosowanych w przypadku innych formatów. Każdy użytkownik Androida jest przeznaczony dla innej osoby fizycznej. Na przykład tymczasowy użytkownik gość może zostać przypisany do znajomego, który pożycza samochód od właściciela. Aby uwzględnić takie przypadki 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.

Komponent, 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ć podstawowy komponent platformy Androida, sterownik jądra systemu (operacyjnego) 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 w naszych repozytoriach wewnętrznych.

Ten komponent ma też wpływ na sposób otrzymywania aktualizacji przez użytkowników. Błąd w ramach lub jądrze systemu (operacyjnego) wymaga aktualizacji oprogramowania układowego bezprzewodowo (OTA), którą każdy producent OEM musi wdrożyć. Błąd w aplikacji lub bibliotece opublikowanej w Google Play (np. w Gmailu, Usługach Google Play lub WebView) może zostać przesłany do użytkowników Androida jako aktualizacja z Google Play.

Powiadamianie partnerów

Gdy w Biuletynie bezpieczeństwa w Androidzie zostanie opisana luka w zabezpieczeniach AOSP, powiadomimy partnerów Androida o szczegółach problemu i udostępnimy poprawki. Lista wersji obsługujących przenoszenie wsteczne zmienia się z każdą nową wersją Androida. Listę obsługiwanych urządzeń uzyskasz od producenta.

Udostępnianie kodu w AOSP

Jeśli błąd bezpieczeństwa występuje w komponencie AOSP, poprawka jest przesyłana do AOSP po udostępnieniu użytkownikom aktualizacji OTA.

Otrzymywanie aktualizacji Androida

Aktualizacje systemu Android są zwykle dostarczane na urządzenia w pakietach aktualizacji OTA. Mogą one pochodzić od producenta OEM, który wyprodukował urządzenie, lub od operatora, który świadczy usługi na tym urządzeniu. Aktualizacje urządzeń Google Pixel są udostępniane przez zespół Google Pixel po przejściu procedury testowania akceptacji technicznej (TA) przez operatora. Google publikuje też obrazy fabryczne Pixela, które można wgrać na urządzenia.

Aktualizowanie usług Google

Oprócz udostępniania poprawek błędów związanych z bezpieczeństwem zespół ds. bezpieczeństwa Androida sprawdza te błędy, aby określić, czy istnieją inne sposoby ochrony użytkowników. Na przykład Google Play skanuje wszystkie aplikacje i usuwa te, które próbują wykorzystać błąd zabezpieczeń. W przypadku aplikacji zainstalowanych spoza Google Play urządzenia z Usługami Google Play mogą też korzystać z funkcji Weryfikacja aplikacji, aby ostrzegać użytkowników przed aplikacjami, które mogą być potencjalnie szkodliwe.

Inne materiały

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

Informacje o bezpieczeństwie znajdziesz w witrynach Android Open Source i dla deweloperów. Dobre miejsca, od których warto zacząć:

Raporty

Czasami zespół ds. bezpieczeństwa Androida publikuje raporty lub dokumenty. Więcej informacji znajdziesz w sekcji Raporty dotyczące bezpieczeństwa.