RSS-Projekt Null Notiz

RSS-Projekt Null

Die Webseite von Google's Project Zero ist eine umfassende Ressource zum Auffinden und Beheben von Sicherheitslücken in Software. Es wird von Googles Sicherheitsforschungsteam geleitet und enthält detaillierte Analysen von Sicherheitsproblemen, Anleitungen und Tutorials für Entwickler, um ihnen zu helfen, Sicherheitslücken in ihren Produkten zu vermeiden.

Notizfaden

Google Project Zero diskutierte die Notwendigkeit von Remote-ASLR-Leaks zur Ausnutzung von Speicherfehlern auf Apple-Geräten. Dies führte zur Entdeckung einer Technik, die einen Zeiger remote leaken konnte, ohne Verletzungen der Speichersicherheit oder Timing-Angriffe. Die Methode gilt für Angriffsflächen, die Daten von Angreifern deserialisieren, re-serialisieren und zurückgeben. Obwohl keine unmittelbare reale Angriffsfläche auf macOS/iOS identifiziert wurde, wurde die Technik anhand eines künstlichen Falls mit NSKeyedArchiver getestet. Das Problem wurde Apple gemeldet und behoben, obwohl aufgrund fehlender nachgewiesener realer Auswirkungen kein öffentlicher Bug-Tracker-Eintrag vorgenommen wurde. Diese neuartige Technik baut auf früheren Arbeiten im Zusammenhang mit Hash-Tabellen-Kollisionsangriffen auf. Historisch gesehen nutzten HashDoS-Angriffe die schlechteste Leistung von Hash-Tabellen, um Denial-of-Service zu verursachen. Frühere Forschungen deuteten auch darauf hin, Hash-Kollisionen zum Leaken von Adressen zu verwenden. Das HashDoS-Konzept kann als ein Angreifer betrachtet werden, der den Zugriff auf bestimmte Hash-Buckets verlangsamt. Dieses Prinzip wurde in Firefox genutzt, um Heap-Adressen durch Timing-Messungen von JavaScript Map-Einfügungen zu leaken. Das Iterieren über Zeiger-Schlüssel-Datenstrukturen kann auch Informationen über Objektadressen preisgeben. Serialisierungsmechanismen, insbesondere solche, die beliebige Objektgraphen zulassen, können unsicher sein. Apples NSKeyedUnarchiver arbeitet mit einer Whitelist von deserialisierbaren Klassen. Ein spezifischer Testfall zielt darauf ab, den Shared-Cache-Zeiger zu leaken, indem Angreifer-Daten mit NSKeyedUnarchiver deserialisiert und re-serialisiert werden. Der Hash des NSNull-Singleton-Objekts wird, wenn er nicht explizit behandelt wird, standardmäßig auf seine Adresse gesetzt, die im Shared Cache gespeichert ist. NSNumber-Instanzen werden je nach numerischem Wert unterschiedlich gehasht. Dictionaries verwenden Hash-Codes modulo der Anzahl der Buckets, um die Platzierung von Schlüsseln zu verwalten.
"Google Project Zero hat seine Richtlinie für die Schwachstellenmeldung aktualisiert und ein "90+30"-Modell eingeführt, um die Entwicklung und Übernahme von Patches zu beschleunigen. Eine bedeutende Herausforderung bleibt jedoch bestehen: die "Patch-Lücke", die Verzögerung zwischen der Veröffentlichung eines Fixes und seiner Installation durch den Benutzer. Project Zero hat eine frühere Verzögerung identifiziert, die "upstream-Patch-Lücke", bei der Upstream-Anbieter bereits Fixes haben, aber downstream-Abhängige sie noch nicht integriert haben. Diese upstream-Lücke verlängert die Lebenszyklen von Schwachstellen erheblich. Um diesem Problem zu begegnen, wird eine neue Testrichtlinie, "Berichtstransparenz", angekündigt. Diese Testrichtlinie sieht vor, dass innerhalb einer Woche nach Meldung einer Schwachstelle öffentlich bekannt gegeben wird, einschließlich des Anbieters, des Produkts, des Meldedatums und des Fristen für die Offenlegung. Die Kernpolitik von 90+30 bleibt bestehen, und auch Google Big Sleep testet diese Richtlinie. Ziel ist es, die upstream-Patch-Lücke durch erhöhte Transparenz zu verringern, downstream-Abhängige zu informieren und bessere Kommunikation zu fördern. Der Test zielt darauf ab, die Zeit von der Meldung bis zur Installation auf dem Benutzergerät zu verfolgen und hervorzuheben, wenn Fixes nicht angewendet werden. Bis zum Fristablauf werden keine technischen Details veröffentlicht; dies ist eine Warnung, kein Leitfaden für Angreifer. Einige Anbieter mögen unerwünschte Aufmerksamkeit erfahren, aber die Vorteile überwiegen die Risiken für eine Minderheit. Das ultimative Ziel ist ein sichereres Ökosystem, in dem Schwachstellen auf Benutzergeräten behoben werden. Dies ist ein Test, und Project Zero wird die Auswirkungen überwachen und die Richtlinien entsprechend anpassen."
Der NSO BLASTPASS iMessage-Exploit war eine Zero-Click- und Zero-Day-Schwachstelle, die iPhones mit der neuesten Version von iOS ohne jegliche Interaktion des Opfers kompromittierte. Der Exploit nutzte PassKit-Anhänge mit schädlichen Bildern, die von einem Angreifer-iMessage-Konto an das Opfer gesendet wurden. Apple veröffentlichte am 7. September 2023 ein außerplanmäßiges Sicherheitsupdate für iOS, um die Schwachstelle zu beheben. Das WebP-Team veröffentlichte ebenfalls einen Lösungsvorschlag für das Problem, der später in Chrome integriert wurde.Die Ursache der Schwachstelle war ein Speicherbeschädigungsproblem im WebP-Format für verlustfreie Bilder, insbesondere in der im Format verwendeten Huffman-Codierung. Die Schwachstelle ermöglichte es einem Angreifer, ungültige Huffman-Bäume zu definieren, was zu Speicherbeschädigung beim Erstellen der Decodierungstabelle führen konnte. Allerdings war das Beschädigungs-Primitiv begrenzt, und das Parsen des Bildes würde kurz nach Auslösung des Fehlers stoppen.Die Ausnutzung der Schwachstelle war ein Rätsel, da unklar war, wie man einen Exploit in einer einmaligen Zero-Click-Konfiguration landen konnte. Das Beschädigungs-Primitiv war sehr begrenzt, und ohne Zugriff auf die Samples war es fast unmöglich zu wissen, wie man die Schwachstelle ausnutzen konnte.Mitte November erhielt der Autor eine Reihe von BLASTPASS PKPass-Beispieldateien und Crash-Logs von fehlgeschlagenen Exploit-Versuchen, die es ihm ermöglichten, die Samples zu analysieren und herauszufinden, wie der Exploit funktionierte. Die Analyse ergab, dass die Schwachstelle durch das Senden einer schädlichen Bilddatei ausgenutzt wurde, die das Speicherbeschädigungsproblem auslöste, und dass dann das begrenzte Beschädigungs-Primitiv verwendet wurde, um beliebigen Code auszuführen.Das WebP-Format ist ein relativ modernes Bilddateiformat, das Huffman-Codierung zur Komprimierung von Bildern verwendet. Das verlustfreie Format verwendet einen RIFF-Container und ein separates verlustfreies Format, in dem die Schwachstelle gefunden wurde. Die Schwachstelle befand sich in der Huffman-Codierung, die im verlustfreien Format verwendet wird, insbesondere in der Art und Weise, wie die Decodierungstabelle erstellt wird.Die Analyse der Samples durch den Autor ergab, dass der Exploit eine Kombination von Techniken verwendete, um beliebigen Code auszuführen, einschließlich der Verwendung des begrenzten Beschädigungs-Primitivs, um einen Funktionszeiger zu überschreiben und dann den schädlichen Code auszuführen. Die Analyse ergab auch, dass der Exploit hochkomplex war und ein tiefes Verständnis des WebP-Formats und der darin verwendeten Huffman-Codierung erforderte.Insgesamt war der NSO BLASTPASS iMessage-Exploit eine hochentwickelte und komplexe Schwachstelle, die ein tiefes Verständnis des WebP-Formats und der darin verwendeten Huffman-Codierung erforderte. Die Ausnutzung der Schwachstelle war ein Rätsel, aber die Analyse der Samples ergab, dass es möglich war, beliebigen Code mithilfe einer Kombination von Techniken auszuführen.
James Forshaw, Forscher bei Google Project Zero, beschreibt die „Gefangenen-Objekt-Fehlerklasse“ in objektorientierten Remote-Technologien wie DCOM und .NET Remoting. Diese Technologien ermöglichen die Entwicklung objektorientierter Schnittstellen, die Prozess- und Sicherheitsgrenzen überschreiten können. Diese Flexibilität hat jedoch Nachteile, darunter das Potenzial für Rechteerhöhungen oder die Ausführung von Remote-Code.Nicht alle Objekte, die remotefähig sind, sind auch sicher. Einige Objekte, wie z. B. XML-Bibliotheken, können beliebigen Script-Code im Kontext eines XSLT-Dokuments ausführen. Wenn ein XML-Dokument-Objekt über die Grenze hinweg zugänglich gemacht wird, könnte ein Client Code im Kontext des Serverprozesses ausführen.Es gibt mehrere Szenarien, die diese Fehlerklasse einführen können, darunter das unbeabsichtigte Teilen unsicherer Objekte, die Verwendung asynchroner Marshalling-Primitive und der Missbrauch integrierter Mechanismen zum Suchen und Instanziieren von Objekten. Beispielsweise führten die Windows Runtime-Bibliotheken einen Fehler ein, indem sie Code zum bestehenden XML DOM Document v6 COM-Objekt hinzufügten, wodurch die runtime-spezifischen Schnittstellen verfügbar gemacht wurden. Dies ermöglichte es einem bösartigen Client, nach der alten IXMLDOMDocument-Schnittstelle zu fragen und diese zu verwenden, um ein XSLT-Skript auszuführen.Ein weiteres Beispiel sind die .NET-Klassen FileInfo und DirectoryInfo, die sowohl nach Wert als auch nach Referenz gemarshallt werden können und verwendet werden können, um eine neue Instanz des Objekts im Prozess des Servers zu erstellen. Ein Angreifer kann dies ausnutzen, indem er eine serialisierte Form des Objekts an den Server sendet, der dann eine neue Instanz des Objekts erstellt. Anschließend kann das erstellte Objekt zurückgelesen werden, wobei es per Referenz an den Angreifer gemarshallt wird.Das letzte erwähnte Szenario ist der Missbrauch der integrierten Mechanismen zum Suchen und Instanziieren von Objekten, um ein unerwartetes Objekt zu erstellen. Beispielsweise kann ein Angreifer in COM die CoCreateInstance-API verwenden, um ein beliebiges COM-Objekt im Kontext des Servers zu erstellen und es an den Client zurückgeben zu lassen. Dies kann ausgenutzt werden, indem ein XML DOM Document-Objekt auf dem Server erstellt, per Referenz an den Client gemarshallt und dann verwendet wird, um beliebigen Code im Kontext des Servers auszuführen.Diese Szenarien unterstreichen die Bedeutung einer sorgfältigen Abwägung der Sicherheitsaspekte bei der Verwendung objektorientierter Remote-Technologien und der Sicherstellung, dass nur sichere Objekte über Sicherheitsgrenzen hinweg geteilt werden.
James Forshaw von Google Project Zero veröffentlichte einen Blogbeitrag über die Entwicklung einer virtuellen Speicherzugriffsfalle unter Windows. Ziel dieser Falle ist es, das Lesen oder Schreiben an eine virtuelle Speicheradresse für eine erhebliche Zeitspanne zu unterbrechen. Dies kann zur Ausnutzung bestimmter Kernel-Schwachstellen verwendet werden. In seinem vorherigen Blogbeitrag schlug Forshaw die Verwendung einer SMB-Datei auf einem Remoteserver oder die missbräuchliche Nutzung der Cloud Filter API vor. Eine neue Funktion in Windows 11 24H2 ermöglicht jedoch den Missbrauch des lokalen SMB-Dateiservers, ohne dass ein Remoteserver benötigt wird. Diese Funktion erlaubt die Angabe des Ziel-TCP-Ports für den SMB-Client über die Kommandozeile, wodurch eine Verbindung zu einem gefälschten SMB-Server hergestellt werden kann. Die neue Funktion ermöglicht die Ausnutzung von Schwachstellen, die als "False File Immutability"-Bugs bekannt sind, und erfordert keinen Administratorzugriff. Forshaw hat seinen Beispiel-Fake-SMB-Server aktualisiert, um die Bindung an einen anderen Port zu ermöglichen, wodurch der Angriff lokal durchgeführt werden kann. Diese Änderung wurde in Windows 11 24H2, welches allgemein verfügbar ist, implementiert und ist standardmäßig aktiviert. Ein Administrator kann diese Funktion zwar über Gruppenrichtlinien deaktivieren, es ist jedoch unwahrscheinlich, dass Nicht-Enterprise-Benutzer diese Einstellung ändern. Forshaw glaubt, dass die standardmäßige Aktivierung dieser Funktion ein Fehler ist, der zukünftig Probleme für Windows verursachen könnte. Insgesamt bietet diese neue Funktion eine neue Möglichkeit, bestimmte Schwachstellen in Windows auszunutzen, und unterstreicht die Bedeutung sorgfältiger Überlegungen bei der Einführung neuer Funktionen in ein Betriebssystem.
- Erste Untersuchung: Google erhielt Kernel-Panic-Logs von Amnesty International, die auf einen im-wild-Exploit (ITW) hinwiesen, der einen Qualcomm-Treiber angriff. - Analyse der Kernel-Panic-Logs: Ohne das Exploit-Beispiel stützte sich Project Zero/TAG auf die Kernel-Panic-Logs, um potenzielle Schwachstellen zu identifizieren. - Schwachstellenentdeckung: Vier der Panic-Logs enthielten nützliche Informationen, die zur Entdeckung von sechs Schwachstellen im Qualcomm-Treiber führten. - Hypothese zur Exploit-Strategie: Eine der Schwachstellen wurde als wahrscheinlich im ITW-Szenario ausgenutzt identifiziert, basierend auf den Crash-Logs. - Details der Fehler: Der Blog-Beitrag beschreibt jede der sechs entdeckten Schwachstellen, einschließlich technischer Details und Code-Snippets für jede. - Zusammenarbeit mit der Threat Analysis Group: Googles Threat Analysis Group (TAG) arbeitete mit Amnesty International zusammen, um die Artefakte bereitzustellen und bei der technischen Analyse zu unterstützen. - Reverse-Engineering-Herausforderung: Die Bestimmung der ausgenutzten Schwachstelle ohne das Exploit-Beispiel erforderte eine gründliche Analyse der Panic-Logs. - Begrenzte Informationen: Die Abwesenheit eines Exploit-Beispiels machte es schwierig, die ausgenutzte Schwachstelle genau zu bestimmen. - Dauer der Fehlersuche: Die Untersuchung und Entdeckung der Schwachstellen dauerte über zwei und ein halb Monate. - Bericht von Amnesty International: Amnesty International veröffentlichte einen Bericht über die gegen ihre Zielgruppe eingesetzten Exploits.