Zespół ds. bezpieczeństwa Androida odpowiada za zarządzanie lukami w zabezpieczeniach odkrytymi w ramach platformy Android i wielu podstawowych aplikacji 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łoszone przez osoby trzecie. Źródła błędów zewnętrznych to m.in. problemy zgłoszone za pomocą formularza dotyczącego podatności, opublikowane i wcześniej opublikowane badania naukowe, powiadomienia od naszych partnerów będących producentami urządzeń oraz publicznie znane problemy publikowane na blogach lub w mediach społecznościowych.
Zgłaszanie problemów z bezpieczeństwem
Każdy deweloper, 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 podatności na zagrożenia.
Błędy oznaczone jako problemy związane z zabezpieczeniami nie są widoczne z zewnątrz, ale mogą zostać udostępnione po ich ocenie lub rozwiązaniu. Jeśli planujesz przesłać poprawkę lub test Compatibility Test Suite (CTS), aby rozwiązać problem z bezpieczeństwem, załącz je w raporcie o błędach i zaczekaj na odpowiedź, zanim prześlesz kod do AOSP.
Posortuj błędy
Pierwszym krokiem w rozwiązaniu problemu z luką w zabezpieczeniach jest określenie wagi błędu i komponentu Androida, którego dotyczy. Poważność określa priorytet problemu, a komponent określa, kto naprawi błąd, kto otrzyma powiadomienie i w jaki sposób poprawka zostanie wdrożona dla użytkowników.
Typy kontekstu
Ta tabela zawiera definicje kontekstów zabezpieczeń sprzętu i oprogramowania. Kontekst może być zdefiniowany przez wrażliwość danych, które zwykle przetwarza, lub obszar, w którym działa. Nie wszystkie konteksty zabezpieczeń są stosowane we wszystkich systemach. Tabela jest posortowana od najmniejszych do największych uprawnień.
| Typ kontekstu | Definicja typu |
|---|---|
| ograniczony kontekst, |
Ograniczone środowisko wykonawcze, w którym są przyznawane tylko minimalne uprawnienia. Na przykład zaufane aplikacje przetwarzające niesprawdzone dane w środowisku piaskownicy. |
| Kontekst bez podwyższonych uprawnień |
Typowe środowisko wykonywania oczekujące na nieuprzywilejowany kod. Na przykład aplikacja na Androida, która działa w domenie SELinux z atrybutem untrusted_app_all.
|
| Kontekst poufny |
Środowisko uprzywilejowanego wykonywania, które może mieć dostęp do rozszerzonych uprawnień, obsługiwać wiele danych osobowych użytkowników lub dbać o integralność systemu. Na przykład aplikacja na Androida z funkcjami, które są zabronione przez domenę SELinux untrusted_app, lub z dostępem do uprawnień privileged|signature.
|
| jądro systemu operacyjnego, |
Funkcje:
|
| Zaufany sprzęt bazowy (THB) | oddzielne komponenty sprzętowe, zwykle w ramach SoC, które zapewniają funkcje kluczowe dla głównych zastosowań urządzenia (np. pasma podstawowe, procesory DSP, procesory graficzne i procesory ML); |
| Łańcuch programu rozruchowego | Komponent, który konfiguruje urządzenie podczas uruchamiania, a potem przekazuje kontrolę systemowi Android. |
| Zaufane środowisko wykonawcze (TEE) | Komponent, który ma być chroniony nawet przed nieprzyjaznym jądrem systemu operacyjnego (np. TrustZone i hipernadzorce, takie jak pKVM, które chronią maszyny wirtualne przed jądrem systemu operacyjnego). |
| Bezpieczne środowisko odizolowane / Bezpieczny element (SE) |
Opcjonalny komponent sprzętowy, który ma być chroniony przed wszystkimi innymi komponentami na urządzeniu oraz przed atakami fizycznymi, zgodnie z definicją podaną w artykule Wprowadzenie do elementów zabezpieczeń. Dotyczy to również układu Titan M, który jest obecny na niektórych urządzeniach z Androidem. |
Poziom
Poważność błędu odzwierciedla potencjalne szkody, które mogą wystąpić w przypadku jego wykorzystania. Aby określić powagę naruszenia, użyj podanych niżej kryteriów.
| Rating | Skutki skutecznego wykorzystania luki |
|---|---|
| Ważne |
|
| Wysoki |
|
| Umiarkowane |
|
| Niski |
|
| Nieznaczny wpływ na bezpieczeństwo |
|
Modyfikatory stawek
Chociaż wagę luki w zabezpieczeniach często można łatwo określić, oceny mogą się zmieniać w zależności od okoliczności.
| Przyczyna | Efekt |
|---|---|
| Wymaga działania w kontekście uprzywilejowanym, aby wykonać atak (nie dotyczy TEE, SE i hipervisorów, takich jak pKVM) | -1 Poziom ważności |
| Szczegóły dotyczące podatności ograniczają wpływ problemu | -1 Poziom ważności |
| obejście uwierzytelniania biometrycznego, które wymaga danych biometrycznych bezpośrednio od właściciela urządzenia; | -1 Poziom ważności |
| kompilator lub konfiguracje platformy łagodzą lukę w zabezpieczeniach w źródłowym kodzie źródłowym; | Umiarkowana waga, jeśli podstawowa luka w zabezpieczeniach ma wagę umiarkowaną lub wyższą. |
| Wymaga fizycznego dostępu do wewnętrznych części urządzenia i jest możliwa nawet wtedy, gdy urządzenie jest wyłączone lub nie zostało odblokowane od momentu włączenia. | -1 Poziom ważności |
| Wymaga fizycznego dostępu do wewnętrznych części 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 |
| Atak lokalny, który wymaga włączenia trybu programisty lub stałych ustawień trybu programisty na urządzeniu (i nie jest błędem w samym trybie programisty). | Nie wyższa niż Niska |
| Jeśli żadna domena SELinux nie może wykonać operacji zgodnie z SEPolicy udostępnionym przez Google. | Nieistotny wpływ na bezpieczeństwo |
Lokalne, bliższe i oddalone
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 e-maila, otrzymanie SMS-a lub połączenie z nieprzyjazną siecią.
Wektory ataku zbliżeniowego są uważane za odległe. Dotyczy to błędów, których można używać tylko atakujący, który jest fizycznie blisko urządzenia docelowego. Przykładem może być błąd wymagający wysyłania nieprawidłowo sformatowanych pakietów Wi-Fi lub Bluetooth. Uważamy, że ataki wykorzystujące łącza ultraszerokopasmowe (UWB) i NFC są bliższe, a zatem zdalne.
Ataki lokalne wymagają, aby atakujący miał wcześniej dostęp do ofiary. W przypadku hipotetycznego przykładu oprogramowania może to być złośliwa aplikacja zainstalowana przez ofiarę lub aplikacja błyskawiczna, której uruchomienie zostało przez nią zaakceptowane.
Urządzenia, które zostały sparowane (np. urządzenia z Bluetooth), są uważane za lokalne. Różnimy sparowane urządzenie od urządzenia, które uczestniczy w procesie parowania.
- Błędy, które obniżają zdolność użytkownika do identyfikacji drugiego urządzenia, z którym jest ono sparowane (np. uwierzytelnianie), są uważane za zbliżone i tym samym zdalne.
- Błędy występujące podczas procesu parowania, ale przed wyrażeniem zgody przez użytkownika (czyli autoryzacji) są uważane za dalekie i dlatego odległe.
- Błędy występujące po wyrażeniu zgody przez użytkownika są uznawane za błędy lokalne, nawet jeśli parowanie ostatecznie się nie powiedzie.
Wektory ataków fizycznych są uważane za lokalne. Dotyczy to błędów, których można używać tylko atakujący, który ma fizyczny dostęp do urządzenia, na przykład błędu w ekranie blokady lub błędu, który wymaga podłączenia kabla USB. Ponieważ urządzenia są często odblokowane, gdy są podłączone do portu USB, ataki wymagające połączenia przez USB są równie poważne niezależnie od tego, czy urządzenie jest odblokowane, czy nie.
Bezpieczeństwo sieciowe
Android zakłada, że wszystkie sieci są wrogie i mogą uruchamiać ataki lub szpiegować ruch. Zabezpieczenia na poziomie łącza (np. szyfrowanie Wi-Fi) chronią komunikację między urządzeniem a punktem dostępu, z którym jest połączone, ale nie zapewniają bezpieczeństwa pozostałych ogniw łańcucha między urządzeniem a serwerami, z którymi się komunikuje.
W przeciwieństwie do tego HTTPS zwykle chroni całą komunikację od końca do końca, szyfrując dane w źródle, a następnie odszyfrowując i weryfikując je dopiero po dotarciu do miejsca docelowego. Z tego powodu luki w zabezpieczeniach sieci na poziomie łącza są oceniane jako mniej poważne niż luki w protokołach HTTPS/TLS: szyfrowanie Wi-Fi samo w sobie nie wystarcza do większości komunikacji w internecie.
Uwierzytelnianie biometryczne
Weryfikacja biometryczna to trudny obszar, a nawet najlepsze systemy mogą zostać oszukane przez osoby o bardzo podobnych cechach (patrz blog dla deweloperów aplikacji na Androida: ulepszenia ekranu blokady i weryfikacji w Androidzie 11). Te oceny powagi odróżniają 2 klasy ataków i mają na celu odzwierciedlenie rzeczywistego zagrożenia dla użytkownika.
Pierwsza klasa 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 atakujący przyklei gumę do żucia do czytnika linii papilarnych, a urządzenie odblokuje się na podstawie pozostałości pozostawionych na czytniku, jest to prosty atak, który można przeprowadzić na dowolnym podatnym urządzeniu. Nie wymaga to znajomości właściciela urządzenia. Ponieważ można go zastosować w większym zakresie i potencjalnie może on wpłynąć na większą liczbę użytkowników, ten atak otrzymuje pełną ocenę wagi (np. wysoką w przypadku obejścia ekranu blokady).
Druga klasa ataków polega na wykorzystaniu instrumentu ataków na prezentacje (spoof), który jest oparty na danych właściciela urządzenia. Czasami te informacje biometryczne są stosunkowo łatwe do zdobycia (na przykład jeśli zdjęcie profilowe w mediach społecznościowych jest wystarczające do oszukania uwierzytelniania biometrycznego, obejście biometryczne otrzyma najwyższą ocenę wagi). Jeśli jednak atakujący musiałby pozyskać dane biometryczne bezpośrednio od właściciela urządzenia (np. za pomocą skanera podczerwienego), byłoby to wystarczająco duża bariera, która ograniczyłaby liczbę osób dotkniętych atakiem. W takim przypadku zastosowano modyfikator -1.
SYSTEM_ALERT_WINDOW i tapjacking
Informacje o naszych zasadach dotyczących SYSTEM_ALERT_WINDOW i aplikacji tapjacking znajdziesz w sekcji „Bezpieczeństwo: usterki tapjackingu/nakładki SYSTEM_ALERT_WINDOW na ekranie, który nie ma wpływu na bezpieczeństwo” na stronie
Bezpieczeństwo: usterki bez wpływu na bezpieczeństwo
w BugHunter University.
Zabezpieczenia dotyczące wielu użytkowników w systemie operacyjnym Android Automotive
Android Automotive OS stosuje model zabezpieczeń dla wielu użytkowników, który różni się od innych formatów. Każdy użytkownik Androida powinien być używany przez inną osobę fizyczną. Na przykład tymczasowy użytkownik-gość może zostać przypisany do znajomego, który pożycza pojazd od właściciela. Aby umożliwić 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 jakim komponencie występuje błąd. Może to być podstawowy element platformy Android, sterownik jądra dostarczony przez producenta oryginalnego sprzętu (OEM) lub jedna z wstępnie zainstalowanych aplikacji na urządzeniach Pixel.
Błędy w kodzie AOSP są poprawiane przez zespół inżynierów Androida. Błędy o niskim priorytecie, błędy w określonych komponentach lub błędy, które są już znane publicznie, można naprawić bezpośrednio w publicznie dostępnej głównej gałęzi AOSP. W przeciwnym razie błędy są naprawiane najpierw w naszych repozytoriach wewnętrznych.
Składnik ma też wpływ na to, jak użytkownicy otrzymują aktualizacje. Błąd w ramowcu lub jądrze wymaga bezprzewodowej aktualizacji oprogramowania, którą musi wdrożyć każdy producent OEM. Błąd w aplikacji lub bibliotece opublikowanej w Google Play (np. Gmail, Usługi Google Play lub WebView) może zostać wysłany do użytkowników Androida jako aktualizacja z Google Play.
Powiadom partnerów
Gdy podatność w AOSP zostanie naprawiona w Biuletynie bezpieczeństwa Androida, powiadomimy partnerów Androida o szczegółach problemu i przekażemy poprawki. Lista wersji, w których można stosować funkcję backport, zmienia się wraz z każdą nową wersją Androida. Aby uzyskać listę obsługiwanych urządzeń, skontaktuj się z producentem.
Publikowanie kodu w AOSP
Jeśli błąd związany z bezpieczeństwem występuje w komponencie AOSP, poprawka jest wysyłana do AOSP po udostępnieniu użytkownikom aktualizacji OTA. Rozwiązania problemów o niskim stopniu ważności można przesyłać bezpośrednio do głównego gałęzi AOSP, zanim będą dostępne na urządzeniach w ramach aktualizacji OTA.
Odbieranie aktualizacji Androida
Aktualizacje systemu Android są zwykle dostarczane na urządzenia za pomocą pakietów aktualizacji OTA. Aktualizacje te mogą pochodzić od producenta OEM lub operatora, który zapewnia obsługę urządzenia. Aktualizacje urządzenia Google Pixel pochodzą od zespołu Google Pixel po przejściu procedury testów technicznych akceptacji (TA) przez operatora. Google publikuje też obrazy fabryczne Pixela, które można zainstalować na urządzeniu.
Aktualizowanie usług Google
Oprócz udostępniania poprawek dotyczących 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ż używać funkcji Weryfikuj aplikacje, aby ostrzegać użytkowników przed potencjalnie szkodliwymi aplikacjami.
Inne materiały
Informacje dla deweloperów aplikacji na Androida: https://developer.android.com
Informacje o bezpieczeństwie znajdziesz w witrynach poświęconych oprogramowaniu typu open source i witrynach dla deweloperów Androida. Dobre miejsca na początek:
Raporty
Czasami zespół ds. bezpieczeństwa Androida publikuje raporty lub dokumenty. Więcej informacji znajdziesz w raportach o zabezpieczeniach.