Diese Woche in Sicherheit: GTA, Apple und Android und unsicherer Start

Als wir zum ersten Mal Tweets über ein Sicherheitsproblem in Grand Theft Auto V sahen, klang es ein bisschen wie ein Troll. „Press ‚alt and f4‘ to unlock a cheat mode“, oder der Hacker, der behauptet, seinen Charakter löschen zu können. [Tez2]’s Warn-Tweet Dass man GTA Online nicht ohne Firewall spielen sollte, klingt wie eine weitere dieser urbanen Online-Legenden. Aber dieser scheint tatsächlich legitim zu sein. NIST ist sogar am Spaß beteiligt und weist CVE-2023-24059 für den Exploit zu.

Beim Spielen eines Online-Spiels senden andere Benutzer eine „Beitrittsanfrage“, um der aktiven Sitzung beizutreten. Diese Pakete können fehlerhafte Daten enthalten, von denen beobachtet wurde, dass sie den Spielclient aus der Ferne zum Absturz bringen. Es wird angenommen, obwohl dies nicht öffentlich bestätigt wurde, dass es sich auch um eine Remote Code Execution (RCE)-Schwachstelle handelt. Es ist wahrscheinlich, dass dieser Aspekt zu einigen der verschiedenen Cheat-Panels hinzugefügt wird, die für dieses 10 Jahre alte Spiel bereits weit verbreitet sind. Anstatt also Ihrem eigenen Charakter unendlich viel Munition und Gesundheit zu geben, können Sie jetzt anderen Spielern Chaos zufügen, möglicherweise bis hin zur Beschädigung ihrer Charakterdateien und deren Sperrung.

Aber warum dort aufhören? Wenn wir Codeausführung im Spiel haben, was hindert einen anderen Spieler daran, einen echten Angriff zu starten? Ein Videospiel ist nicht wie ein Browser in einer Sandbox untergebracht, und nichts hindert einen Festplatten-Wischer-Angriff oder sogar einen Wurm daran, eine Gruppe von Spielern zu kompromittieren. Das Schlimmste ist, dass es sich um ein altes Spiel handelt, und obwohl es eine große Spielerbasis gibt, ist es nicht garantiert, dass es behoben wird. Es gibt mindestens ein Projekt, das darauf abzielt, eine Firewall zu sein, um das Problem zu verhindern.

Die 19 und 20 Jahre alten Bugs von XNU

[Adam Doupé] scheint ein Händchen dafür zu haben, alte Fehler in Apples Code zu finden, und dieses Mal sind es zwei wirklich alte Fehler in Apples Kernel XNU. Das erste ist ein Problem in dlil.c, der Netzwerkschnittstellenhandler. Dieses Problem ist ein Typumwandlungsfehler, bei dem ein int in ein uint_16 umgewandelt wird. Wenn diese Umwandlung überläuft, wird der Wert zu einer großen negativen Zahl, und der nachfolgende Datenschreibvorgang unterläuft den Puffer und schreibt außerhalb der Grenzen. Die Methode, um diese auszulösen, ist etwas knifflig, da sie die Erstellung von 65536 Netzwerkschnittstellen erfordert.

Es gibt zwei Ansätze, um diese Bedingung auszulösen. Das erste ist das einfachste, ein winziges Skript, das als root ausgeführt wird und aufruft ifconfig wiederholt, um die Schnittstellen zu erstellen. Während dies als Teil einer Exploit-Kette interessant sein könnte, ist die interessantere Idee, einen schädlichen USB-Dongle zu erstellen, der sich als mehrere Netzwerkschnittstellen darstellt. Der Rest des Beitrags ist [Adam]Versuch von , den Underflow in einen Exploit umzuwandeln. Er hat es nicht ganz geschafft, aber es sieht so aus, als wäre es möglich.

Der zweite Fehler ist noch älter, ein 20 Jahre alter Fehler in XNUs ndrv.c, der Raw-Socket-Handler. Es ist ein Randfall, bei dem eine verknüpfte Liste mit zwei Mitgliedern nicht ordnungsgemäß durchlaufen wird, eines der Listenmitglieder freigegeben wird, aber das übergeordnete Element immer noch einen Zeiger auf den jetzt freigegebenen Speicher enthält. Beide Fehler wurden nun in den neuesten iOS- und macOS-Versionen behoben.

Android (ARM) auch

Android sollte nicht ausgelassen werden, mit einer großartigen Beschreibung von [Man Yue Mo] von Github Security Lab über ein Problem in der Arm-Mali-GPU, die als Teil von Pixel 6-Geräten geliefert wird. Mit großer Ironie wird uns erzählt, wie das eine Nicht-Google-Element im All-Google-Telefon zur Ausnutzung des Kernel-Space aus einer App heraus führte. Insbesondere ist es der Treiber für diese GPU und wie er mit JIT-Speicher umgeht, bei dem es sich um Speichersegmente handelt, die vom Kernel verwaltet werden und auf die vom Userspace und direkt von der GPU zugegriffen wird. Und wie Sie vielleicht erwarten, kann es zu Problemen führen, wenn drei verschiedene Komponenten gleichzeitig auf den Speicher zugreifen.

In diesem Fall besteht das Problem darin, wie mit der Räumung umgegangen wird. Diese Speicherblöcke werden verarbeitet und können dann an den freien Speicher zurückgegeben werden. Eine Leistungsoptimierung durch den Treiber besteht darin, Speicherpuffer „warm“ zu halten, den Kernel nicht wirklich aufzufordern, sie freizugeben, und den Zuordnungsprozess zu überspringen, wenn die nächste Anforderung benötigt wird. Das Problem ist, dass Speicher in diesem Schwebezustand als „räumbar“ gilt und der Kernel diese Bereiche freigeben kann, ohne dies über den GPU-Treiber zu tun. Dadurch befindet sich das System in einem seltsamen Zustand, in dem der GPU-Treiber und der Benutzerbereich immer noch gültige Zeiger auf einen Speicherort haben, der Kernel ihn jedoch als frei markiert hat. Der eigentliche Spaß beginnt, wenn der freigewordene Speicherplatz von einem angreifenden Prozess beansprucht und ein gefälschtes JIT-Objekt an seine Stelle gesetzt wird. Durch eine geschickte Speichermanipulation kann dies genutzt werden, um eine Userspace-Zuordnung des Kernelcodes zu erstellen, der dann gelesen und geschrieben werden kann. Und der einfachste Schritt von dort aus besteht darin, die Userspace-Anwendung einfach zu ändern, sodass sie als Root ausgeführt wird.

Es ist ein cleverer Fund, aber was wirklich auffällt, ist das Problem, es zu reparieren. Dies wurde den Android-Ingenieuren im Juli 2022 gemeldet, und einige Wochen später wurde der Bericht als „Wird nicht behoben“-Problem geschlossen. Es gibt hier einen legitimen Punkt, dass es nicht der Android-Code ist, der das Problem enthält, und dies musste im ARM-Treiber behoben werden. ARM veröffentlichte ein Update, das das Problem weniger als drei Monate später, im August 2022, behob. Eine koordinierte Offenlegung war mit ARM für November geplant, aber es scheint, dass die Android-Ingenieure den Fehler vollständig fallen ließen und bis zum Januar-Update warteten, um es endlich auszuliefern Patch für Android-Benutzer. Und als es schließlich kam, wurde es als ein ganz anderer Fehler verfolgt, was bedeutet, dass der ursprüngliche Bericht geschlossen und vergessen wurde. Es ist ein bisschen entmutigend zu sehen, dass Google eine so leichtfertige Haltung gegenüber einer Schwachstelle dieser Schwere bei seinem eigenen Produkt zeigt.

Wieder KSMBD

Es sieht langsam nach einer schlechten Idee aus, den Server Message Block Daemon-Treiber in den Linux-Kernel zu packen, da wir einen weiteren Pre-Auth-Integer-Unterlauf haben, der zu Denial-of-Service führt. Forscher von Sysdig fanden den Fehler dieses Mal, indem sie auf der Grundlage des vorherigen ZDI-22-1690 recherchierten, das ein ernsthafteres RCE im selben Kernelmodul war. Dieser unterscheidet sich ein wenig von anderen Integer-Unterläufen, die wir uns angesehen haben. Die Wrap-Around-Natur von Ganzzahlen verhindert stattdessen, dass diese Sicherheitsanfälligkeit ernster wird.

Das eigentliche Problem besteht darin, dass während der SMB-Authentifizierung die Datenstruktur des entfernten Benutzers ein Paar Längenwerte enthält, die zum Analysieren der eingehenden Authentifizierungsdaten verwendet werden. Es ist offensichtlich, dass diesen Werten nicht implizit vertraut wird, und es werden einige gute Fehlerprüfungen durchgeführt, um einen trivialen Pufferüberlauf zu verhindern. Der Fall, der uns zum Stolpern bringt, ist wann nt_len ist weniger als CIFS_ENCPWD_SIZE, und der resultierende Wert ist negativ. Wenn diese negative ganze Zahl in unsigned umgewandelt wird size_t in einem memcpy() aufrufen, wird die negative Ganzzahl auf einen nahezu maximalen Wert „ausgepackt“. size_t. Die Speicherkopierfunktion versucht die Anweisung, aber dies ist eine ziemlich unkontrollierte Operation und erreicht schließlich einen unzugänglichen Speicher und versetzt den Kernel in Panik. Bisher scheint es keine Möglichkeit zu geben, diesen speziellen Fehler in ein echtes RCE umzuwandeln. Und außerdem weiß nach so vielen Jahren sicherlich jeder, dass man einen SMB-Dienst nicht vertrauenswürdigen Benutzern zugänglich machen sollte, oder?

Unsicherer Start

Während sich Secure Boot nicht ganz als das dystopische PC-Lock-in erwiesen hat, das einige von uns befürchtet haben, ist es immer noch gelegentlich ein Problem, damit umzugehen, wenn man versucht, etwas auf einem kaputten Computer zu reparieren. Benötigen Sie eine benutzerdefinierte Bootdiskette, um ein Tool auszuführen? Ja, Zeit, Secure Boot zu deaktivieren. Aber es gibt ein paar Fälle, in denen es hilfreich ist, wie zum Beispiel zu verhindern, dass Boot-Malware in ein verschlüsseltes System eindringt. Vielleicht spricht etwas für eine bekannte Größe wie Secure Boot.

Aus diesem Grund ist es etwas seltsam, dass MSI beschlossen hat, es in einem Firmware-Update, das im vergangenen Januar veröffentlicht wurde, massenhaft auf ihren Desktop-Motherboards zu kompromittieren. Und beachten Sie, dass MSI den sicheren Start nicht deaktiviert hat. Überprüfen Sie die Firmware-Einstellungen oder führen Sie sie aus mokutil --sb-state, und diese Computer würden Sie gerne darüber informieren, dass Secure Boot noch aktiviert ist. Aber eine obskure Firmware-Einstellung, „Image Execution Policy“, ist auf „Always Execute“ eingestellt – also würde Secure Boot immer noch die Signatur auf dem Boot-Stack prüfen und ihn dann booten, unabhängig davon, was gefunden wurde. Ich zitiere nur den Entdecker, [Dawid Potocki]Fazit von : „Vertrauen Sie nicht darauf, dass die von Ihnen aktivierten Sicherheitsfunktionen funktionieren, TESTEN SIE SIE!“

RCE von QT Verletzlichkeit Insekt

Die QT-Suite hat ein Problem, bei dem in QML-Code (Qt Modeling Language) eingebettetes Javascript eines von zwei Problemen bei der Speicherverarbeitung auslösen und RCE erreichen könnte. Es gibt einige Meinungsverschiedenheiten zwischen Cisco Talos und QT darüber, ob es sich um einen einfachen Fehler oder eine Sicherheitslücke handelt. QML-Code ist ausdrücklich als Benutzeroberflächencode für Anwendungen gedacht und sollte niemals nicht vertrauenswürdigen Code ausführen. Tatsächlich wäre die Sicherheitslücke laut QT jede „Anwendung, die nicht vertrauenswürdige Eingaben an QtQml weitergibt“.