Vorsicht: Windows-Dienste, Teil II

Gestern hatten wir über eine als Designfehler kolportierte Sicherheitslücke in Windows NT ff. berichtet -- eigene Forschungen dazu legen inzwischen den Schluss nahe, dass Microsoft doch in der Pflicht ist.

In Pocket speichern vorlesen Druckansicht 697 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Peter Siering

Wie gestern berichtet hat Chris Paget ein White Paper sowie Beispielcode veröffentlicht, um darin eine Sicherheitslücke in Windows NT und Nachfolgern aufzuzeigen. Paget kam zu dem Schluss, dass es sich dabei um einen Designfehler in Windows handelt. Eine Aussage, der Microsoft widersprach -- mit der Konsequenz, dass es wohl auch keine Korrektur dafür geben wird. c't-eigene Forschungen legen inzwischen nahe, dass Microsoft wohl Recht hat, dennoch aber gut daran täte, eine Fehlerkorrektur vorzunehmen.

Der Reihe nach: Ein wesentlicher Punkt der von Paget beschriebenen Lücke ist, dass sich Windows-Anwendungen gegenseitig Botschaften zuschicken können. Diese Tatsache mag mancher als Designfehler werten. Sie ist aber eine Windows-immanente Eigenschaft, die an vielen Stellen benutzt wird, sei es, um andere Anwendungen fernzusteuern oder den Datenaustausch zwischen Programmen zu ermöglichen. Eine Änderung dieser Architektur würde darauf hinaus laufen, dass ein Gutteil heutiger Software nicht mehr funktionierte.

Wichtig für das Ausnutzen der Lücke ist, dass der Nachrichtenaustausch unter bestimmten Umständen auch zwischen Prozessen möglich ist, die in unterschiedlichen Sicherheitskontexten laufen. Ein Anwender kann mit entsprechend ausgelegter Software Dienste unter Windows dazu bringen, untergeschobenen Code im Kontext des System-Kontos auszuführen. Eine solche Software müsste aber schon spezielle Lücken des jeweiligen Dienstes und seiner Art kennen, mit bestimmten Nachrichten umzugehen, um einen Buffer-Overflow geeignet auszunutzen. Das hat Microsoft -- von den eigenen Diensten abgesehen -- nicht in der Hand, sondern nur die Hersteller der jeweiligen Dienste.

Das letzte relevante Detail in Pagets Papier klingt so unglaublich, dass wir erst jetzt nach eingehender Prüfung darauf eingehen: Eine besondere Botschaft spielt dabei eine wichtige Rolle, die Windows einer Applikation auf Antrag regelmäßig zuschickt: WM_TIMER. Man kann eine solche Botschaft mit dem PostMessage-API-Aufruf an einen anderen Prozess senden und die Adresse einer Callback-Funktion mitgeben. Diese Funktion ruft das Programm, das die Botschaft erhält, dann auf. Es ist also möglich, allein durch das Versenden einer Botschaft Code in einem anderen Prozess anzuspringen -- das kann durchaus auch ein Dienst sein, der in einem anderen Sicherheitskontext mit weitergehenden Rechten läuft.

Interessant sind die Details: Schickt man eine WM_TIMER-Botschaft an einen x-beliebigen Prozess mit einer Adresse, die dort ins Nichts beziehungsweise auf ungültigen Code zeigt, erscheint nicht etwa eine Fehlermeldung. Offenbar greift eine Ausnahmebehandlungsroutine. Es sieht also zunächst danach aus, als passiere nichts. Trifft man jedoch ausführbaren Code, so führt das System diesen treuglaubend aus. Dabei spielt es keine Rolle, ob die "angegriffene" Applikation selbst bei Windows Timer angefordert hat oder nicht. Windows prüft weder die IDs, die es beim Anfordern von Timern vergibt, noch die Adresse einer dabei registrierten Callback-Funktion.

Warum Microsoft zulässt, dass allein durch das Versenden einer Botschaft direkt Code in einem anderen Prozess "anspringbar" ist, ohne dass die Parameter einer solchen Nachricht zumindest auf Plausiblität geprüft werden, ist kaum nachvollziehbar. Insofern müssen wir unser Fazit revidieren: Der Software-Hersteller zahlt seinen Preis für das nicht lupenreine Design. Er ist in der Pflicht, die Behandlung der WM_TIMER-Botschaften zu überdenken und schnellstens um eine Prüfung der Plausiblität zu ergänzen. Das wäre dann auch eine gute Gelegenheit, den Windows-Botschaftenwald auf weitere solche Zeitbomben hin zu untersuchen ... (ps)