Abb. 1. Gequetscht, aber nicht gebrochen. Der Windows-Rechner, dessen Code kürzlich auf Github veröffentlicht wurde , erwies sich als eine von zwei getesteten Anwendungen, die nicht hängen blieben und nicht im Gegensatz zu dem im Jahr 2000 entwickelten Fuzzer von Fenstermeldungen standen. Die Fenstergröße wurde speziell vergrößert, um unscharfe Artefakte anzuzeigen

Es ist Zeit für den zweiten Teil unserer Bemühungen, alte Fuzzing-Techniken auf modernen Systemen zu testen. Wenn Sie verpasst haben, ist hier der erste Teil . Dieses Mal werden wir Windows 10 mithilfe von Fuzzing-Techniken aus dem im Jahr 2000 veröffentlichten Artikel „Empirische Untersuchung der Zuverlässigkeit von Windows NT-Anwendungen mithilfe von Zufallstests“ (auch bekannt als „NT Fuzzing Report“) von Justin Forrester und Barton Miller testen.

Die Forscher testeten 33 Anwendungen von Windows NT und einer früheren Version von Windows 2000 auf Anfälligkeit für verzerrte Fenstermeldungen und zufällige Maus- und Tastaturereignisse. Seit Dr. Miller den Fuzzer-Code veröffentlicht hat, haben wir genau dieselben Tools wie die ursprünglichen Autoren verwendet, um nach Fehlern in modernen Windows-Anwendungen zu suchen.

Die Ergebnisse sind nahezu identisch: Vor 19 Jahren stürzten 100% der getesteten Anwendungen ab oder stürzten ab, wenn sie auf verzerrte Fenstermeldungen stießen. Heute hat der gleiche Fuzzer 93% der getesteten Anwendungen fallen lassen oder aufgehängt. Nur zwei standen, einschließlich unseres alten Freundes Calculator (Abb. 1). Wir haben auch einen Fehler (aber kein Sicherheitsproblem) unter Windows gefunden.

Eine kurze Einführung in Windows

Was sind Fenstermeldungen und warum stürzen sie ein Programm ab?

Windows-GUI-Anwendungen sind ereignisgesteuert: Mausbewegungen, Tastendrücke, Tastenanschläge usw. Eine ereignisgesteuerte Anwendung unternimmt nichts, bis sie ein Ereignis empfängt. Sobald ein Ereignis empfangen wurde, führt die Anwendung die Aktion basierend auf dem Ereignis aus und erwartet dann andere Ereignisse. Kommt Ihnen das bekannt vor? Diese Architektur hat auf Plattformen wie node.js ein zweites Leben erhalten.

Fenstermeldungen sind eine Windows-Ereignisbenachrichtigungsmethode . Jeder von ihnen hat einen numerischen Code, der einem bestimmten Ereignis zugeordnet ist . Jede Nachricht hat einen oder mehrere Parameter, die üblicherweise als lParam und wParam bezeichnet werden . Sie definieren detailliertere Informationen über das Ereignis. Beispiele für solche Informationen sind die Koordinaten der Mausbewegung, welche Taste gedrückt wird oder welcher Text im Fenster angezeigt werden soll. Diese Nachrichten können vom Programm selbst, vom Betriebssystem oder von anderen Programmen gesendet werden. Sie können jederzeit und in beliebiger Reihenfolge eintreffen und müssen vom Antrag auf der Empfängerseite bearbeitet werden.

Auswirkungen auf die Sicherheit

Vor Windows Vista konnte ein Prozess mit geringen Berechtigungen eine Nachricht an einen Prozess mit hohen Berechtigungen senden. Mit der richtigen Kombination von Nachrichten können Sie in diesem Prozess Code ausführen. In Vista wurden diese „subversiven Angriffe“ weitgehend durch UIPI und durch die Isolierung von Systemdiensten in einer separaten Sitzung geschützt.

Eine falsche Verarbeitung von Fenstermeldungen beeinträchtigt die Sicherheit moderner Windows-Systeme aus zwei Gründen wahrscheinlich nicht. Erstens können Fensternachrichten nicht über das Netzwerk gesendet werden. Zweitens ist es für einen Angreifer nicht sehr nützlich, eine Anwendung zum Absturz zu bringen oder Code mit derselben Berechtigungsstufe auszuführen. Wahrscheinlich war es den Autoren des NT-Fuzzing-Berichts klar. Sie geben keine Sicherheitserklärungen ab, weisen jedoch zutreffend darauf hin, dass Fehler bei der Verarbeitung von Fenstermeldungen einen Mangel an strengen Tests implizieren.

In einigen Bereichen kann die Ausführung von Code mit denselben Berechtigungen die Sicherheit beeinträchtigen. Einige Anwendungen kombinieren verschiedene Sicherheitsprimitive, um eine künstliche Berechtigungsstufe zu erstellen, die ursprünglich nicht im Betriebssystem gefunden wurde. Ein typisches Beispiel ist eine Sandbox zum Rendern in einem Browser. Browserhersteller sind sich dieser Probleme bewusst und haben Schritte unternommen, um sie zu beheben . Ein weiteres Beispiel sind Antivirenprodukte. Dort arbeitet das Control Panel mit normalen Berechtigungen, ist jedoch von anderen Antivirenmodulen isoliert.

Testmethode

Um alle Anwendungen in der Testsuite zu fuzzeln, haben wir denselben grundlegenden Code und dieselbe Fuzzing-Technik verwendet, die im ersten NT-Bericht beschrieben wurden. Insbesondere verwendete der Fazzer sowohl im SendMessage- als auch im PostMessage- Modus drei Iterationen von 500.000 Nachrichten mit 42 Seeds und drei Iterationen von 500.000 Nachrichten mit 1.337 Seeds. Die Ergebnisse erschienen nach nur einer Iteration jeder Methode.

Wir haben zufällige Maus- und Tastatureingaben aus Zeitgründen und aus dem Wunsch heraus verpasst, uns ausschließlich auf Fenstermeldungen zu konzentrieren. Wir ermutigen auch diejenigen, die Tests wiederholen und die Ergebnisse bestätigen möchten.

Fallstricke

Für Fuzzer in Windows 10 mussten zwei kleinere Änderungen vorgenommen werden. Passen Sie es zunächst für eine 64-Bit-Plattform an. Mit der zweiten Änderung konnte fuzzer mithilfe des Befehlszeilenarguments ein bestimmtes Fensterhandle auswählen. Das Fuzzing eines bestimmten Deskriptors ist eine schnelle Lösung für das Fuzzing von UWP- Anwendungen (Universal Windows Platform) . Das ursprüngliche Programm konzentriert sich auf das Fuzzing von Fenstern, die zu einem bestimmten Prozess gehören, aber alle UWP-Anwendungen zeigen ihre Benutzeroberfläche über denselben Prozess an (Abb. 2). Dies bedeutet, dass der Fuzzer nicht zum Hauptfenster der UWP-Anwendung geleitet werden kann.


Abb. 2. Auf der UWP-Plattform gehören alle Anwendungen zu einem Prozess ( ApplicationFrameHost.exe ). Um diese Anwendungen zu verwirren, musste ich den ursprünglichen NT-Fuzzer ändern und ihn auf bestimmte Fenstergriffe richten

Bei der Fuzzer-Modifikation gab es einen schwerwiegenden Fehler: Die für die beiden Hauptquellen für zufällige Eingaben ausgewählten Werte, die Argumente lParam und wParam für SendMessage und PostMessage , sind auf 16-Bit-Ganzzahlen beschränkt. Beide Argumente sind 32-Bit unter 32-Bit-Windows und 64-Bit unter 64-Bit-Windows. Das Problem tritt in Fuzz.cpp , wo lParam und wParam :

  wParam = (UINT) rand(); lParam = (LONG) rand(); 

Die Funktion rand () gibt eine Zahl im Bereich [0, 2 ¹⁶ ] zurück, wodurch die Menge der getesteten Werte stark eingeschränkt wird. Wir haben diesen Fehler während des Tests absichtlich gespeichert, damit die Ergebnisse genau mit der Originalarbeit übereinstimmen.

Getestete Anwendungen

Im ursprünglichen NT-Bericht wurden 33 Programme getestet. Wir haben nur 28, da nur eine Version jedes Programms zum Testen verwendet wird. Das Windows-Software-Ökosystem hat sich seit 2000 erheblich verändert, obwohl überraschend viel unverändert bleibt. Die Microsoft Office-Suite enthält dieselben Programme wie in den ursprünglichen Tests. Netscape Communicator hat sich zu Firefox entwickelt. Adobe Acrobat wurde in Adobe Reader umbenannt, ist aber weiterhin gültig. Sogar Winamp veröffentlichte 2018 eine neue Version, die einen fairen Vergleich mit dem ursprünglichen Bericht ermöglicht. Einige veraltete Programme mussten jedoch ersetzt werden. Im Folgenden finden Sie eine Liste der Änderungen und Gründe dafür:

• CD-Player ⇨ Windows Media Player: Die CD-Player-Funktionalität ist im neuen Programm enthalten.
  
• Eudora ⇨ Windows Mail: Qualcomm befasst sich jetzt eher mit Chips als mit E-Mail-Clients. Da Eudora nicht mehr vorhanden ist, wurde stattdessen der Standard-Windows-Mail-Client getestet.
  
• Befehl AntiVirus ⇨ Avast Free Edition: Befehl AntiVirus ist nicht mehr verfügbar. Es wurde durch Avast als beliebtestes Antivirenprogramm von Drittanbietern ersetzt.
  
• GSView ⇨ Fotos: GSView wird nicht mehr unterstützt. Es wurde durch den Standard-Windows-Foto-Viewer ersetzt.
  
• JavaWorkshop Net NetBeans-IDE: Die JavaWorkshop-IDE wird nicht mehr unterstützt. NetBeans scheint eine gute kostenlose Alternative zu sein, die dem Geist dessen entspricht, was überprüft werden muss.
  
• Sichere CRT ⇨ BitVise SSH: Sichere CRT ist noch vorhanden, zum Herunterladen der Testversion ist jedoch ein sehr langes Webformular erforderlich. BitVise SSH bot einen Schnellstart an.
  
• Telnet ⇨ Putty: Die Telnet-Anwendung ist unter Windows noch vorhanden, jetzt ist sie jedoch eine Konsolenanwendung. Um die GUI zu verwischen, haben wir sie durch Putty ersetzt, den beliebten Open-Source-Terminalemulator für Windows.
  
• Wir haben Freecell und Solitaire in der Microsoft Solitaire Collection aus dem Windows App Store-Anwendungskatalog gefunden.

Die spezifische Version der Anwendung wird in der Ergebnistabelle angezeigt. Das gesamte Fuzzing wurde auf einem 64-Bit-System Windows 10 Pro Version 1809 (Build 17763.253) durchgeführt.

Ergebnisse

Wie im ursprünglichen Bericht erwähnt, sollten die Ergebnisse nicht als Sicherheitslücken angesehen werden, sondern als Indikator für die Zuverlässigkeit und Qualität von Software.

"Schließlich bilden unsere Ergebnisse einen quantitativen Ausgangspunkt, um die relative Verbesserung der Softwarezuverlässigkeit zu beurteilen."

- Aus der „empirischen Studie zur Zuverlässigkeit von Windows NT-Anwendungen mithilfe von Zufallstests“ von Justin Forrester und Barton Miller

Die Zahlen sind nicht besonders ermutigend, obwohl sich die Situation verbessert. Im ersten NT-Bericht stürzten alle Anwendungen ab oder hingen am Fuzzing. Jetzt überlebten zwei Programme: der Taschenrechner und Avast Antivirus die Phaseneinteilung von Fenstermeldungen ohne negative Konsequenzen. Wir loben die Teams von Avast und Windows Calculator für ihren Ansatz bei fehlerhaften Fenstermeldungen. Das Calculator-Team hat sich zusätzlichen Respekt verdient, wenn es darum geht, den Quellcode zu öffnen und zu demonstrieren, wie eine hochwertige UWP-Anwendung erstellt wird. In Tabelle 1 finden Sie alle Fuzzing-Ergebnisse sowie die spezifische Version der verwendeten Software.

Tabelle 1. Ergebnisse der Wiedergabe des ursprünglichen Fuzzing unter Windows 10. Nach 19 Jahren verarbeiten fast alle Anwendungen verzerrte Fenstermeldungen immer noch nicht richtig

Windows Bug?

Leider herrschte Neugierde und wir mussten eine Ausnahme machen. Es schien, dass mehrere nicht verwandte Anwendungen von einem gemeinsamen Problem betroffen waren. Das Debuggen hat gezeigt, dass das Problem mit der Nachricht WM_DEVICECHANGE . Als der Fuzzer diese Nachricht sendete, stürzte sogar die einfachste Anwendung ab - HelloWorld, das offizielle Beispiel der Windows-API (Abb. 3).


Abb. 3. Die 32-Bit-Datei HelloWorld.exe stürzt ab, wenn eine Fenstermeldung von fuzzer empfangen wird. Dies sollte nicht passieren, da das Programm völlig einfach ist. Es versteht sich, dass das Problem irgendwo in Windows liegt

Nach dem Fall von HelloWorld wurde uns sofort klar, dass das Problem nur 32-Bit-Anwendungen betrifft, nicht jedoch 64-Bit-Anwendungen. Einige schnelle Fehlerbehebungen zeigten, dass der Absturz in wow64win.dll auftritt, einer 32-Bit-Anwendungskompatibilitätsschicht für 64-Bit . Meine oberflächliche (und möglicherweise falsche) Analyse des Problems lässt wow64win.dll!whcbfnINDEVICECHANGE den Schluss ziehen, dass die wow64win.dll!whcbfnINDEVICECHANGE wParam als Zeiger auf die Struktur DEV_BROADCAST_HANDLE64 im Zielprogramm betrachtet. Die Funktion konvertiert diese Struktur zur Kompatibilität mit 32-Bit-Anwendungen in die Struktur DEV_BROADCAST_HANDLE32 . Der Fehler tritt auf, weil der vom Fuzzer generierte wParam Wert einen ungültigen Speicher anzeigt.

wParam ist eine schlechte Idee, wParam als lokalen Zeiger zu behandeln, obwohl es wahrscheinlich eine bewusste Entwurfsentscheidung für Benachrichtigungen über Wechselmedien war, um mit älteren 32-Bit-Windows-Anwendungen zu arbeiten. Es ist jedoch immer noch falsch, dass Sie eine andere Anwendung problemlos zum Absturz bringen können. Wir haben das Problem an MSRC gemeldet, obwohl die Sicherheitsgrenze nicht überschritten wurde. Sie bestätigten, dass der Fehler kein Sicherheitsproblem war. Wir hoffen, in einer zukünftigen Version von Windows eine Lösung für dieses allgemein akzeptierte seltsame Problem zu finden.

Fazit

Fenstermeldungen werden unterschätzt und häufig als unzuverlässige Eingabe für Windows-Programme ignoriert. Selbst 19 Jahre nach dem Erscheinen des ersten Fuzzers von Open-Source-Fenstermeldungen frieren 93% der getesteten Anwendungen immer noch ein oder stürzen ab, wenn dasselbe Programm gestartet wird. Es ist jedoch ermutigend, dass einige Anwendungen diese verzerrten Eingaben ordnungsgemäß verarbeiten: Dies bedeutet, dass einige Organisationen über Frameworks und institutionelles Wissen verfügen, um solche Fehler zu vermeiden.

Natürlich kann Fuzzer auf viele Arten verbessert werden, aber selbst die einfachste Methode stürzte 93% der Anwendungen ab. In einigen Fällen überschreiten Fensternachrichten möglicherweise sogar die eigentliche Sicherheitsgrenze. Wenn Sie dieses Gebiet erkunden, hoffen wir, dass Sie die Ergebnisse teilen.