Google vs Microsoft; Google Research Team macht zwei weitere Windows 7/8-Sicherheitsanfälligkeiten öffentlich

Der Krieg zwischen Google und Microsoft eskaliert, als Google zwei weitere Windows 7 und Windows 8 Sicherheitsanfälligkeiten offenbart.

Das Google Research Team hat am Donnerstag zwei weitere ungepatchte Windows-Sicherheitsanfälligkeiten öffentlich gemacht, nachdem die selbst auferlegte 90-tägige Wartefrist von Google Project Zero vor der Offenlegung von Fehlerdetails abgelaufen war.

Microsoft, das solche öffentlichen Offenlegungen nicht gerne sieht, hat erklärt, dass es eine der beiden Sicherheitsanfälligkeiten in seinem kommenden Sicherheitsbulletin für den Patch-Dienstag im Februar beheben wird. Der zweite Fehler scheint kein großes Sicherheitsproblem darzustellen.

Die Leser erinnern sich vielleicht daran, dass das Google-Forschungsteam eine Privilegieneskalationsanfälligkeit in Windows 7 nach Ablauf der selbst auferlegten 90-tägigen Wartefrist öffentlich gemacht hatte. Googles Offenlegung am 29. Dezember belebte die Diskussionen über Offenlegungen zwischen Sicherheitsenthusiasten und entfachte Groll sowie öffentliche Stellungnahmen von beiden Unternehmen.

Microsoft möchte, dass Google ein koordiniertes Programm zur Offenlegung von Sicherheitsanfälligkeiten befolgt, und hatte Google gebeten, die Offenlegung der Sicherheitsanfälligkeit bis zu den Sicherheitsbulletins im Januar, die diese Woche veröffentlicht wurden, zurückzuhalten. Google hingegen verlässt sich auf seine selbst auferlegte 90-tägige Moratorium, weshalb es ablehnte und mit seiner Offenlegung fortfuhr.

Chris Betz von Microsoft erklärte: „Obwohl die Einhaltung den angekündigten Zeitplan von Google für die Offenlegung einhält, fühlt sich die Entscheidung weniger nach Prinzipien an und mehr wie ein ‚Gotcha‘, wobei die Kunden die Leidtragenden sein könnten. Was für Google richtig ist, ist nicht immer das Richtige für die Kunden. Wir fordern Google auf, den Schutz der Kunden zu unserem gemeinsamen Hauptziel zu machen.“

Der Krieg zwischen den Technologieriesen ist noch lange nicht vorbei, da das Google-Forschungsteam zwei weitere Windows-Sicherheitsanfälligkeiten öffentlich gemacht hat. Beide Sicherheitsanfälligkeiten sind nachfolgend aufgeführt:

Problem Nr. 127, das Microsoft am 17. Oktober 2013 gemeldet wurde, wurde am 15. Januar 2014 öffentlich gemacht

Plattform: Windows 7 32/64 Bit, Windows 8+ nicht anfällig
Klasse: Sicherheitsumgehung Der Systemaufruf NtPowerInformation führt eine Überprüfung durch, dass der Aufrufer ein Administrator ist, bevor er einige spezifische Energie-Funktionen ausführt. Die Überprüfung erfolgt in der Funktion PopUserIsAdmin. Die grobe Implementierung ist: BOOLEAN PopUserIsAdmin() {
SECURITY_SUBJECT_CONTEXT ctx; SeCaptureSecurityContext(&ctx); return SeTokenIsAdmin(SeQuerySubjectContextToken(&ctx));
} Unter Windows 7 kann diese Überprüfung umgangen werden, da die Funktion SeTokenIsAdmin das Nachahmungsniveau des Tokens nicht berücksichtigt und der Rest des Codes dies ebenfalls nicht berücksichtigt. Daher können Sie das Token eines Administrators als normaler Benutzer nachahmen (durch verknüpftes Token oder Entführung eines Systemtokens) und die geschützten Funktionen aufrufen. Unter Windows 8+ wurde die Methode SeTokenIsAdmin geändert, um das Nachahmungsniveau zu überprüfen, sodass sie nicht anfällig ist. Es ist unklar, ob dies ernsthafte Sicherheitsauswirkungen hat oder nicht, daher wird es so offengelegt, wie es ist. Einige Funktionen werden ebenfalls durch eine Berechtigungsüberprüfung überprüft, jedoch wird der Subjektkontext separat erfasst, sodass es ein TOCTOU-Fenster zwischen den Überprüfungen gibt, das ausgenutzt werden könnte. Für PoC-Zwecke habe ich mich entschieden, die Funktion 45 „PopRequestPowerListInfo“ zu verwenden (die keine speziellen Tricks erfordert). Diese Funktion hat auch eine theoretische Ganzzahlüberlaufanfälligkeit, abhängig davon, wie viel Sie die Größe von PopPowerRequestObjectCount drücken können. Im Anhang befindet sich ein einfaches PoC, das das Problem zur Ausführung unter Windows 7 demonstriert. Um zu reproduzieren, folgen Sie den Schritten. 1) Stellen Sie sicher, dass Sie als Administrator mit geteiltem Token arbeiten, da das PoC das verknüpfte Token verwendet, um ein Administrator-Token zu erhalten. Für einen normalen Benutzer könnten Sie einfach ein Token von einem Dienst erfassen.

2. Führen Sie das PoC aus, es sollten Aufrufe erfolgen, einer ohne Nachahmung und einer mit. Erwartetes Ergebnis:
   Beide Aufrufe sollten STATUS_ACCESS_DENIED (0xC0000022) zurückgeben. Beobachtetes Ergebnis:
   Die erste Überprüfung schlägt mit STATUS_ACCESS_DENIED fehl, während die zweite mit STATUS_SUCCESS erfolgreich ist. PoC zum Download => 1 2

Problem Nr. 128, das Microsoft am 17. Oktober 2013 gemeldet wurde, wurde am 15. Januar 2014 öffentlich gemacht

Plattform: Windows 7, 8.1 Update 32/64 Bit
Klasse: Sicherheitsumgehung/Informationsoffenlegung Die Funktion CryptProtectMemory ermöglicht es einer Anwendung, Speicher für eines von drei Szenarien zu verschlüsseln: Prozess, Anmeldesitzung und Computer. Bei Verwendung der Anmeldesitzungsoption (CRYPTPROTECTMEMORY_SAME_LOGON-Flag) wird der Verschlüsselungsschlüssel basierend auf der Anmeldesitzungs-ID generiert, dies dient dem Austausch von Speicher zwischen Prozessen, die innerhalb derselben Anmeldesitzung ausgeführt werden. Da dies auch zum Senden von Daten von einem Prozess zu einem anderen verwendet werden kann, unterstützt es das Extrahieren der Anmeldesitzungs-ID aus dem Nachahmungstoken. Das Problem ist, dass die Implementierung in CNG.sys das Nachahmungsniveau des Tokens nicht überprüft, wenn die Anmeldesitzungs-ID erfasst wird (unter Verwendung von SeQueryAuthenticationIdToken), sodass ein normaler Benutzer auf Identifikationsniveau nachahmen und Daten für diese Anmeldesitzung entschlüsseln oder verschlüsseln kann. Dies könnte ein Problem darstellen, wenn es einen Dienst gibt, der anfällig für einen Named-Pipe-Platzierungsangriff ist oder verschlüsselte Daten in einem weltweit lesbaren gemeinsamen Speicherbereich speichert. Dieses Verhalten könnte natürlich Design sein, jedoch ist es schwer zu sagen, da ich nicht an dem Design beteiligt war. Die Dokumentation besagt, dass der Benutzer den Client nachahmen muss, was ich so verstehe, dass er im Namen des Clients handeln sollte, anstatt sich als Client zu identifizieren. Im Anhang befindet sich ein einfaches PoC, das das Problem demonstriert. Um zu reproduzieren, folgen Sie den Schritten. 1) Führen Sie Poc_CNGLogonSessionImpersonation.exe von der Befehlszeile aus

2. Das Programm sollte „Verschlüsselung stimmt nicht überein“ ausgeben, um anzuzeigen, dass die beiden Verschlüsselungen derselben Daten nicht übereinstimmten, was impliziert, dass der Schlüssel unterschiedlich war. Erwartetes Ergebnis:
   Beide Aufrufe sollten die gleichen verschlüsselten Daten zurückgeben, oder der zweite Aufruf sollte fehlschlagen. Beobachtetes Ergebnis:
   Beide Aufrufe sind erfolgreich und geben unterschiedliche verschlüsselte Daten zurück. PoC-Download => Zip-Datei

Microsoft wird nur eine der Sicherheitsanfälligkeiten in seinem Februar-Patch-Dienstag beheben, wobei es sagte, dass die andere Sicherheitsanfälligkeit kein Sicherheitsrisiko darstellt. Sowohl Microsoft als auch Google gaben an, dass sie keinen Beweis dafür haben, dass eine der drei öffentlich gemachten Sicherheitsanfälligkeiten in der Wildnis ausgenutzt wurde.