Google jest zaangażowany w promowanie równości rasowej dla społeczności czarnych. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Aktualizacje i zasoby bezpieczeństwa

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 strony trzecie. Źródła zewnętrznych błędów obejmują problemy zgłoszone za pomocą szablonu Android Security Issue , opublikowane i wstępnie opublikowane badania naukowe, niezależni opiekunowie projektów typu open source, powiadomienia od naszych partnerów producentów urządzeń oraz publicznie ujawnione problemy publikowane na blogach lub w mediach społecznościowych.

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

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 zgłaszania luk w zabezpieczeniach .

Błędy oznaczone jako problemy z bezpieczeństwem nie są widoczne na zewnątrz, ale mogą ostatecznie zostać ujawnione po ocenie lub rozwiązaniu problemu. Jeśli planujesz przesłać poprawkę lub test Compatibility Test Suite (CTS) w celu rozwiązania problemu z bezpieczeństwem, dołącz go do zgłoszenia błędu i poczekaj na odpowiedź przed przesłaniem kodu do AOSP.

Segregacja błędów

Pierwszym zadaniem związanym z obsługą luki w zabezpieczeniach jest określenie wagi błędu i tego, który składnik systemu Android jest zagrożony. Istotność określa priorytet problemu, a składnik określa, kto naprawia błąd, kto jest powiadamiany oraz w jaki sposób poprawka jest wdrażana u użytkowników.

Rodzaje procesów

Ta tabela zawiera definicje typów procesów. Typ procesu można zdefiniować na podstawie typu aplikacji lub procesu lub obszaru, w którym działa. Ta tabela jest uporządkowana od najmniej do najbardziej uprzywilejowanych.

Rodzaj procesu Definicja typu
Ograniczony proces Proces działający w bardzo ograniczonej domenie SELinux.
LUB
Proces, który jest znacznie bardziej ograniczony niż zwykła aplikacja.
Nieuprzywilejowany proces Aplikacja lub proces innej firmy.
LUB
Aplikacja lub proces działający w domenie untrusted_app aplikacji SELinux.
Proces uprzywilejowany Aplikacja lub proces z możliwościami, które byłyby zabronione przez domenę untrusted_app SELinux.
LUB
Aplikacja lub proces z ważnymi uprawnieniami, których nie może uzyskać aplikacja innej firmy.
LUB
Wbudowany komponent sprzętowy na urządzeniu, który nie jest częścią zaufanej bazy obliczeniowej (TCB).
Zaufana baza obliczeniowa (TCB) Funkcjonalność, która 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 (np. Komponenty sprzętowe urządzenia), ma możliwość ładowania skryptów do komponentu jądra ( na przykład eBPF), procesora pasma podstawowego lub jest jedną z kilku usług użytkownika, które są uważane za odpowiednik jądra: init , ueventd i vold .
Program rozruchowy Składnik, który konfiguruje urządzenie podczas rozruchu, a następnie przekazuje kontrolę do systemu operacyjnego Android.
Zaufane środowisko wykonawcze (TEE) Składnik, który ma być chroniony nawet przed wrogim jądrem.
Element zabezpieczający (SE) Opcjonalny komponent zaprojektowany do ochrony przed wszystkimi innymi komponentami urządzenia i przed fizycznym atakiem, zgodnie z definicją we wprowadzeniu do elementów zabezpieczonych .

Surowość

Waga błędu zwykle odzwierciedla potencjalne szkody, które mogłyby wystąpić, gdyby błąd został pomyślnie wykorzystany. Aby określić wagę, użyj następujących kryteriów.

Ocena Konsekwencje udanej eksploatacji
Krytyczny
  • Nieuprawniony dostęp do danych zabezpieczonych przez SE
  • Wykonanie dowolnego kodu w TEE lub SE
  • Zdalne wykonanie dowolnego kodu w procesie uprzywilejowanym, programie ładującym lub TCB
  • Zdalna trwała odmowa usługi (niesprawność urządzenia: całkowicie trwała lub wymagająca ponownego flashowania całego systemu operacyjnego lub przywrócenia ustawień fabrycznych)
  • Zdalne obejście wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub równoważnego zachowania
  • Zdalne pomijanie wymagań dotyczących interakcji z użytkownikiem dla dowolnego programisty, ustawień zabezpieczeń lub prywatności
  • Zdalne bezpieczne obejście rozruchu
  • Obejście mechanizmów bezpieczeństwa zaprojektowanych w celu zapobieżenia nieprawidłowemu działaniu krytycznych elementów sprzętowych (na przykład zabezpieczeń termicznych)
Wysoki
  • Lokalne obejście bezpiecznego rozruchu
  • Całkowite obejście podstawowej funkcji bezpieczeństwa (takiej jak SELinux, FDE lub seccomp)
  • Zdalne wykonanie dowolnego kodu w nieuprzywilejowanym procesie
  • Lokalne wykonanie dowolnego kodu w procesie uprzywilejowanym, programie ładującym lub bazie TCB
  • Nieuprawniony dostęp do danych zabezpieczonych przez TEE
  • Ataki na SE, które skutkują przejściem na mniej bezpieczną implementację
  • Lokalne obejście wymagań dotyczących interakcji użytkownika podczas instalacji pakietu lub równoważnego zachowania
  • Zdalny dostęp do chronionych danych (dane ograniczone do uprzywilejowanego procesu)
  • Lokalna trwała odmowa usługi (niesprawność urządzenia: trwała lub wymagająca ponownego flashowania całego systemu operacyjnego lub przywrócenia ustawień fabrycznych)
  • Zdalne obejście wymagań dotyczących interakcji użytkownika (dostęp do funkcji lub danych, które normalnie wymagałyby inicjacji użytkownika lub zgody użytkownika)
  • Przesyłanie poufnych informacji przez niezabezpieczony protokół sieciowy (na przykład HTTP i niezaszyfrowany Bluetooth), gdy żądający oczekuje bezpiecznej transmisji (pamiętaj, że nie dotyczy to szyfrowania Wi-Fi, takiego jak WEP)
  • Ogólny bypass do głębokiej obrony lub wykorzystania technologii łagodzenia skutków w bootloaderze lub TEE
  • Ogólne obejście zabezpieczeń systemu operacyjnego, które izolują od siebie dane aplikacji lub profile użytkowników
  • Lokalne obejście wymagań dotyczących interakcji z użytkownikiem dla dowolnego programisty, ustawień zabezpieczeń lub prywatności
  • Luka kryptograficzna w standardowym zabezpieczeniu warstwy transportowej (TLS), która umożliwia ataki typu man-in-the-middle
  • Obejście blokady ekranu
  • Obejście ochrony urządzenia / ochrony przywracania ustawień fabrycznych / ograniczeń operatora
  • Ukierunkowane zapobieganie dostępowi do służb ratunkowych
  • Pomijanie wymagań dotyczących interakcji użytkownika, które są zabezpieczone przez TEE
Umiarkowany
  • Zdalne wykonanie dowolnego kodu w ograniczonym procesie
  • Zdalna tymczasowa odmowa usługi (zdalne zawieszenie lub ponowne uruchomienie)
  • Lokalne wykonanie dowolnego kodu w procesie nieuprzywilejowanym
  • Ogólne obejście dla głębokiej obrony lub wykorzystania technologii łagodzenia skutków w procesie uprzywilejowanym lub w TCB
  • Pomijanie ograniczeń ograniczonego procesu
  • Zdalny dostęp do niezabezpieczonych danych (dane normalnie dostępne dla każdej aplikacji zainstalowanej lokalnie)
  • Lokalny dostęp do chronionych danych (dane ograniczone do uprzywilejowanego procesu)
  • Lokalne obejście wymagań dotyczących interakcji użytkownika (dostęp do funkcji, które normalnie wymagałyby inicjacji użytkownika lub pozwolenia użytkownika)
  • Luka kryptograficzna w standardowych kryptograficznych prymitywach, która umożliwia wyciek zwykłego tekstu (nie prymitywy używane w TLS)
  • Omijanie szyfrowania lub uwierzytelniania Wi-Fi w sposób, który umożliwia atakującemu połączenie się z urządzeniem z Androidem działającym jako hotspot lub z punktem dostępu do sieci (AP), do którego jest podłączone urządzenie
Niska
  • Lokalne wykonanie dowolnego kodu w procesie ograniczonym
  • Luka kryptograficzna w niestandardowym użyciu
  • Ogólne obejście do głębokiej ochrony na poziomie użytkownika lub wykorzystanie technologii łagodzenia skutków w nieuprzywilejowanym procesie
Brak wpływu na bezpieczeństwo (NSI)
  • Luka w zabezpieczeniach, której wpływ został złagodzony przez co najmniej jeden modyfikator oceny lub zmiany architektury specyficznej dla wersji, tak że efektywna ważność jest poniżej Niska, chociaż problem z kodem może pozostać

Modyfikatory oceny

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

Powód Efekt
Wymaga uruchomienia jako uprzywilejowanego procesu do wykonania ataku -1 dotkliwość
Szczegóły dotyczące luki ograniczają wpływ problemu -1 dotkliwość
Konfiguracje kompilatora lub platformy ograniczają lukę w kodzie źródłowym Umiarkowana dotkliwość, jeśli bazowa luka jest umiarkowana lub wyższa
Wymaga fizycznego dostępu do wewnętrznych elementów urządzenia i jest nadal możliwy, jeśli telefon jest wyłączony lub nie został odblokowany od momentu włączenia -1 dotkliwość
Wymaga fizycznego dostępu do wewnętrznych elementów urządzenia, gdy telefon jest włączony i został wcześniej odblokowany -2 nasilenie
Lokalny atak, który wymaga odblokowania bootloadera Nie wyżej 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 w trybie programisty). Nie wyżej niż Niski
Jeśli żadna domena SELinux nie może przeprowadzić operacji w ramach SEPolicy dostarczonej przez Google Brak wpływu na bezpieczeństwo

Lokalny kontra zdalny

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 podczas przeglądania strony internetowej, czytania wiadomości e-mail, odbierania wiadomości SMS lub łączenia się z nieprzyjazną siecią. Na potrzeby naszych ocen istotności zespół ds. Bezpieczeństwa Androida uważa również „bliższe” wektory ataku za zdalne. Obejmują one błędy, które mogą zostać wykorzystane tylko przez atakującego znajdującego się fizycznie w pobliżu urządzenia docelowego, na przykład błąd wymagający wysyłania zniekształconych pakietów Wi-Fi lub Bluetooth. Zespół ds. Bezpieczeństwa Androida uważa, że ​​ataki oparte na NFC są bliższe, a zatem zdalne.

Ataki lokalne wymagają od ofiary uruchomienia aplikacji poprzez zainstalowanie i uruchomienie aplikacji lub wyrażenie zgody na uruchomienie aplikacji błyskawicznej . Na potrzeby ocen ważności zespół ds. Bezpieczeństwa Androida również traktuje 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 w ekranie blokady lub taki, który wymaga podłączenia kabla USB. Należy pamiętać, że ataki wymagające połączenia USB mają taką samą wagę, niezależnie od tego, czy urządzenie ma zostać odblokowane, czy nie; Często zdarza się, że urządzenia są odblokowywane po podłączeniu do portu USB.

Bezpieczeństwo Wi-Fi

Android zakłada, że ​​wszystkie sieci są wrogie i mogą przeprowadzać ataki lub szpiegować ruch. Aby upewnić się, że przeciwnicy na poziomie sieci nie omijają ochrony danych aplikacji, Android zdecydowanie zachęca, aby cały ruch sieciowy korzystał z szyfrowania od końca do końca. Szyfrowanie na poziomie łącza jest niewystarczające.

Element, którego dotyczy problem

Zespół programistów odpowiedzialny za naprawienie błędu zależy od tego, w którym komponencie znajduje się 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 małej 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 najpierw zostaną naprawione w naszych wewnętrznych repozytoriach.

Komponent jest również czynnikiem wpływającym na sposób uzyskiwania aktualizacji przez użytkowników. Błąd we frameworku lub jądrze wymaga aktualizacji oprogramowania układowego OTA (over-the-air), którą każdy producent OEM musi wypchnąć. 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 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ń.

Udostępnienie kodu AOSP

Jeśli błąd bezpieczeństwa występuje w składniku AOSP, poprawka jest wypychana do AOSP po wydaniu OTA użytkownikom. Poprawki problemów o niskim poziomie istotności można przesyłać bezpośrednio do głównej gałęzi AOSP, zanim poprawka zostanie udostępniona urządzeniom za pośrednictwem OTA.

Otrzymywanie aktualizacji Androida

Aktualizacje systemu Android są zwykle dostarczane na urządzenia za pośrednictwem pakietów aktualizacji OTA. Te aktualizacje mogą pochodzić od producenta OEM, który wyprodukował urządzenie, lub operatora, który świadczy usługi na urządzeniu. Aktualizacje urządzenia Google Pixel pochodzą od zespołu Google Pixel po przejściu procedury testowej akceptacji technicznej przewoźnika (TA). Google publikuje również obrazy fabryczne Pixela, które można ładować z boku na urządzenia.

Aktualizowanie usług Google

Oprócz dostarczania poprawek do błędów bezpieczeństwa, zespół bezpieczeństwa Androida przegląda 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 wszystkie aplikacje, które próbują wykorzystać błąd bezpieczeństwa. W przypadku aplikacji zainstalowanych spoza Google Play urządzenia z Usługami Google Play mogą również używać funkcji Weryfikuj aplikacje, aby ostrzegać użytkowników o aplikacjach, które mogą być potencjalnie szkodliwe.

Inne zasoby

Informacje dla programistó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 do rozpoczęcia:

Raporty

Czasami zespół ds. Bezpieczeństwa Androida publikuje raporty lub oficjalne dokumenty. Aby uzyskać więcej informacji, zobacz Raporty bezpieczeństwa .