W tym tygodniu w bezpieczeństwie: GTA, Apple i Android oraz niepewny rozruch


Kiedy po raz pierwszy zobaczyliśmy tweety o problemie z bezpieczeństwem w Grand Theft Auto V, brzmiało to trochę jak troll. „Naciśnij„ alt i f4 ”, aby odblokować tryb oszustwa” lub hakera, który twierdzi, że może usunąć twoją postać. [Tez2]ostrzegawczy tweet że nie powinieneś grać w GTA Online bez zapory ogniowej, brzmi jak kolejna z miejskich legend online. Ale ten rzeczywiście wydaje się uzasadniony. NIST nawet bierze udział w zabawie, przypisując CVE-2023-24059 do exploita.

Podczas grania w grę online inni użytkownicy wysyłają „prośbę o dołączenie”, aby dołączyć do aktywnej sesji. Te pakiety mogą zawierać zniekształcone dane, które, jak zaobserwowano, powodują zdalną awarię klienta gry. Uważa się, choć nie zostało to publicznie potwierdzone, że jest to również luka umożliwiająca zdalne wykonanie kodu (RCE). Wydaje się prawdopodobne, że ten aspekt zostanie dodany do niektórych różnych paneli oszukiwania, które są już szeroko stosowane w tej 10-letniej grze. Więc teraz, zamiast po prostu dawać swojej postaci nieskończoną amunicję i zdrowie, możesz siać spustoszenie wśród innych graczy, być może aż do uszkodzenia ich plików postaci i zbanowania ich.

Ale po co się na tym zatrzymywać? Jeśli mamy wykonanie kodu w grze, co powstrzymuje innego gracza przed rozpoczęciem prawdziwego ataku? Gra wideo nie jest piaskownicą jak przeglądarka i nic nie stoi na przeszkodzie, aby atak wycieraczki dysku lub nawet robak zaatakował grupę graczy. Najgorsze jest to, że jest to stara gra i chociaż istnieje duża baza graczy, nie ma gwarancji, że zostanie naprawiona. Istnieje co najmniej jeden projekt, który ma być zaporą ogniową, aby zapobiec problemowi.

XNU w wieku 19 i 20 lat Bugs

[Adam Doupé] wydaje się mieć talent do znajdowania starych błędów w kodzie Apple, a tym razem jest to para naprawdę starych błędów w jądrze Apple, XNU. Pierwszy to problem w dlil.c, program obsługi interfejsu sieciowego. Ten problem jest błędem rzutowania typu, w którym int jest rzutowany na uint_16. Jeśli to rzutowanie się przepełni, wartość staje się dużą liczbą ujemną, a kolejny zapis danych powoduje niedopełnienie bufora i zapisy poza zakresem. Metoda uruchomienia tego jest nieco skomplikowana, ponieważ wymaga utworzenia 65536 interfejsów sieciowych.

Istnieją dwa podejścia do wyzwalania tego warunku. Pierwszy jest najprostszy, mały skrypt działający jako root, który wywołuje ifconfig wielokrotnie, aby utworzyć interfejsy. Chociaż może to być interesujące jako część łańcucha exploitów, bardziej interesującym pomysłem jest stworzenie złośliwego klucza sprzętowego USB, który przedstawia się jako wiele interfejsów sieciowych. Reszta postu jest [Adam]próba przekształcenia niedomiaru w exploit. Nie do końca mu się to udało, ale wygląda na to, że jest to możliwe.

Drugi błąd jest jeszcze starszy, 20-letni błąd w XNU ndrv.c, surowy moduł obsługi gniazda. Jest to skrajny przypadek, w którym połączona lista z dwoma członkami jest niewłaściwie prowadzona, jeden z członków listy jest zwalniany, ale element nadrzędny nadal zawiera wskaźnik do zwolnionej pamięci. Oba błędy zostały teraz naprawione w najnowszych wersjach iOS i macOS.

Android (ARM) też

Nie można pominąć Androida, który ma świetny opis [Man Yue Mo] z Github Security Lab, o problemie z GPU Arm Mali dostarczanym jako część urządzeń Pixel 6. Z wielką ironią dowiedzieliśmy się, jak jeden element spoza Google w telefonie Google doprowadził do wykorzystania przestrzeni jądra z poziomu aplikacji. W szczególności jest to sterownik dla tego GPU i sposób, w jaki obsługuje on pamięć JIT, czyli segmenty pamięci zarządzane przez jądro i dostępne dla przestrzeni użytkownika i bezpośrednio przez GPU. I jak można się spodziewać, posiadanie trzech różnych komponentów jednocześnie uzyskujących dostęp do pamięci może powodować problemy.

W tym przypadku problemem jest sposób postępowania z eksmisją. Te fragmenty pamięci są przetwarzane, a następnie można je zwrócić do bezpłatnego sklepu. Optymalizacja wydajności przez sterownik polega na utrzymywaniu „ciepłych” buforów pamięci, a nie proszeniu jądra o ich zwolnienie i pomijaniu procesu alokacji, gdy potrzebne jest następne żądanie. Problem polega na tym, że pamięć w tym stanie zawieszenia jest uważana za „możliwą do eksmisji”, a jądro może zwolnić te regiony bez robienia tego za pomocą sterownika GPU. To pozostawia system w dziwnym stanie, w którym sterownik GPU i przestrzeń użytkownika nadal mają prawidłowe wskaźniki do lokalizacji pamięci, ale jądro oznaczyło ją jako wolną. Prawdziwa zabawa zaczyna się, gdy zwolniona lokalizacja pamięci zostaje zajęta przez proces atakujący, a na jej miejsce zostaje umieszczony fałszywy obiekt JIT. Dzięki sprytnej manipulacji pamięcią można to wykorzystać do stworzenia mapowania kodu jądra w przestrzeni użytkownika, który można następnie odczytywać i zapisywać. Najprostszym krokiem jest po prostu zmodyfikowanie aplikacji przestrzeni użytkownika, aby działała jako root.

To sprytne znalezisko, ale to, co naprawdę się wyróżnia, to problem z jego naprawieniem. Zostało to zgłoszone inżynierom Androida w lipcu 2022 r., a kilka tygodni później zgłoszenie zostało zamknięte jako problem „Nie da się naprawić”. Jest tutaj uzasadniony punkt, że to nie kod Androida zawiera problem i trzeba to naprawić w sterowniku ARM. ARM wydał aktualizację, która naprawiła problem niecałe trzy miesiące później, w sierpniu 2022 r. Skoordynowane ujawnienie zostało zaplanowane z ARM na listopad, ale wygląda na to, że inżynierowie Androida całkowicie usunęli błąd i czekali do styczniowej aktualizacji, aby ostatecznie wysłać patch dla użytkowników Androida. A kiedy w końcu się pojawił, został wyśledzony jako zupełnie inny błąd, co oznaczało, że oryginalny raport został zamknięty i zapomniany. To trochę przygnębiające, gdy Google pokazuje tak nonszalanckie podejście do tak poważnej luki we własnym produkcie.

KSMBD Znowu

Umieszczenie sterownika Server Message Block Daemon w jądrze Linuksa zaczyna wyglądać na zły pomysł, ponieważ mamy kolejny niedostatek liczb całkowitych przed uwierzytelnieniem, prowadzący do odmowy usługi. Badacze z Sysdig znaleźli tym razem lukę, opierając się na poprzednim ZDI-22-1690, który był poważniejszym RCE w tym samym module jądra. Ten różni się nieco od innych niedopełnień całkowitoliczbowych, którym się przyglądaliśmy. Zamiast tego zawijana natura liczb całkowitych chroni tę lukę przed poważniejszą luką.

Prawdziwy problem polega na tym, że podczas uwierzytelniania SMB struktura danych od zdalnego użytkownika zawiera parę wartości długości, które są używane do analizowania przychodzących danych uwierzytelniających. Oczywiste jest, że wartości te nie są domyślnie zaufane i przeprowadza się pewne dobre sprawdzanie błędów, aby zapobiec trywialnemu przepełnieniu bufora. Przypadek, który nas potyka, to kiedy nt_len jest mniej niż CIFS_ENCPWD_SIZE, a otrzymana wartość jest ujemna. Kiedy ta ujemna liczba całkowita jest rzutowana na unsigned size_t w memcpy() wywołania, ujemna liczba całkowita jest „rozpakowywana” do wartości prawie maksymalnej size_t. Funkcja kopiowania pamięci podejmie próbę wykonania instrukcji, ale jest to raczej niekontrolowana operacja iw końcu dociera do niedostępnej pamięci i powoduje panikę w jądrze. Jak dotąd wydaje się, że nie ma sposobu, aby zamienić tę konkretną wadę w prawdziwy RCE. A poza tym po tylu latach chyba każdy wie, żeby nie narażać usługi SMB na niepowołanych użytkowników, prawda?

Niepewny rozruch

Chociaż Bezpieczny rozruch nie do końca okazał się dystopijną blokadą komputera, której niektórzy z nas się obawiali, nadal czasami trudno jest sobie z tym poradzić, próbując naprawić coś na zepsutej maszynie. Potrzebujesz niestandardowego dysku rozruchowego, aby uruchomić narzędzie? Tak, czas wyłączyć bezpieczny rozruch. Ale jest kilka przypadków, w których jest to pomocne, na przykład zapobieganie przedostawaniu się złośliwego oprogramowania rozruchowego do zaszyfrowanego systemu. Być może jest coś do powiedzenia na znaną ilość, taką jak bezpieczny rozruch.

Dlatego trochę dziwne jest to, że MSI zdecydowało się masowo skompromitować to na swoich płytach głównych do komputerów stacjonarnych w aktualizacji oprogramowania układowego wypchniętej w styczniu ubiegłego roku. I zauważ, że MSI nie wyłączył bezpiecznego rozruchu. Sprawdź ustawienia oprogramowania układowego lub uruchom mokutil --sb-state, a te maszyny chętnie poinformują Cię, że Bezpieczny rozruch jest nadal włączony. Ale niejasne ustawienie oprogramowania układowego „Zasady wykonywania obrazu” jest ustawione na „Zawsze wykonuj” — więc Bezpieczny rozruch nadal sprawdza podpis na stosie rozruchowym, a następnie uruchamia go niezależnie od tego, co zostanie znalezione. Po prostu zacytuję odkrywcę, [Dawid Potocki]wniosek: „Nie ufaj, że jakiekolwiek włączone funkcje bezpieczeństwa działają, PRZETESTUJ ICH!”

RCE QT Słaby punkt Błąd

Pakiet QT ma problem polegający na tym, że JavaScript osadzony w kodzie QML (Qt Modeling Language) może wywołać jeden z dwóch problemów z obsługą pamięci i osiągnąć RCE. Pomiędzy Cisco Talos i QT istnieje pewna różnica zdań co do tego, czy jest to zwykły błąd, czy też luka w zabezpieczeniach. Kod QML jest jawnie pomyślany jako kod interfejsu użytkownika dla aplikacji i nigdy nie powinien wykonywać niezaufanego kodu. W rzeczywistości, według QT, luką w zabezpieczeniach byłaby dowolna „aplikacja, która przekazuje niezaufane dane wejściowe do QtQml”.





Źródło : https://hackaday.com/2023/01/27/this-week-in-security-gta-apple-and-android-and-insecure-boot/