Project Zero to zespół Google, który odpowiada za znajdowanie luk bezpieczeństwa w różnych produktach, a następnie prywatne zgłaszanie ich odpowiedniemu dostawcy. Istnieje 90-dniowy termin na rozwiązanie problemu , zanim zostanie on upubliczniony. W niektórych przypadkach może być również oferowany 14-dniowy okres karencji.
Google Project Zero wcześniej zgłaszał poważne problemy we własnych produktach Google, a także produktach innych firm, takich jak Windows, iPhone, procesory graficzne Qualcomm Adreno, GitHub i inne. Teraz publicznie zgłosił błąd w systemie operacyjnym Chrome po tym, jak odpowiedni zespół nie naprawił go w przydzielonych 90 dniach.
Pytanie dotyczy tego, jak system operacyjny Chrome obsługuje urządzenia USB, gdy urządzenie jest zablokowane. Zasadniczo system operacyjny Chrome używa USBGuard do konfigurowania list dozwolonych i zablokowanych urządzeń USB. Jednak nieprawidłowe ustawienia tej platformy mogą spowodować, że nieuwierzytelnione urządzenia USB nie będą mogły uzyskać dostępu do jądra i pamięci masowej komputera.
Jak opisuje Jann Horn, badacz bezpieczeństwa Google Project Zero , USBGuard w systemie operacyjnym Chrome ma czarną listę, która nie uwierzytelnia urządzeń USB za pomocą określonych deskryptorów interfejsu klasy na ekranie blokady. Jednak po tym sprawdzeniu wszystkie inne interfejsy są dozwolone.
Oznacza to, że chociaż nieuwierzytelnione urządzenie USB będzie prawidłowo zablokowane na ekranie blokady, inne urządzenia mogą emulować urządzenie pamięci masowej, modyfikować jądro atakującego, aby nie było wyświetlane jako urządzenie USB i być uwierzytelniane. Dzieje się tak, ponieważ klasa USB jest nieistotna dla jądra, więc umożliwia również modyfikację z pozornie uwierzytelnionego urządzenia. Horn zauważa, że:
Oprócz problemu polegającego na tym, że sterowniki urządzeń, które nie należą do tych klas interfejsów USB, mają dużą liczbę powierzchni ataku, istnieje inny problem związany z tym podejściem: jądro często nie dba o to, za jaką klasę USB podaje się urządzenie. być. Sterowniki USB na ogół działają nawet dla standardowych protokołów: sterownik wskazuje z niskim priorytetem, że chciałby łączyć się z urządzeniami zgodnymi ze standardami przy użyciu odpowiedniej klasy interfejsu USB, ale także wskazuje z wysokim priorytetem, że chciałby łączyć się z określonymi urządzeniami USB w oparciu o na identyfikatorze dostawcy i identyfikatorze produktu bez zwracania uwagi na klasę interfejsu USB.
[…] Jeśli używamy maszyny z Linuksem z odpowiednim sprzętem (używam płyty deweloperskiej NET2380, ale prawdopodobnie można to również zrobić z odblokowanym telefonem Pixel lub Raspberry Pi Zero W lub czymś podobnym) do emulacji USB Mass Storage device using (this) , i naprawić jeden wiersz w jądrze atakującego, tak aby podszywał się pod billboard, a nie urządzenie pamięci masowej.
Ten problem został oznaczony jako luka o wysokim poziomie ważności i został prywatnie zgłoszony zespołowi Chrome OS 24 lutego. oparte na sterownikach, a nie na deskryptorach interfejsu klas. 11 maja zespół Chrome OS udostępnił aktualizacje postępów, ale ponieważ nie był w stanie naprawić błędu w wyznaczonym 90 dni, problem został publicznie ujawniony 24 maja.
Nie jest jasne, kiedy zostanie wydana poprawka, ale ważne jest, aby pamiętać, że jest to lokalna luka, która wymaga od atakującego ręcznego włożenia dysku USB w celu złamania zabezpieczeń urządzenia i jego jądra. Nie można go używać zdalnie, ale działa jako wektor ataku dla innych exploitów, jeśli pozostawisz komputer z systemem operacyjnym Chrome bez nadzoru, nawet jeśli jest zablokowany.
Dodaj komentarz