(0) exportieren Drucken
Alle erweitern

Grundlegendes zu Shims

Funktionsweise von Shims

Anwendungsverhalten und Kompatibilität in Microsoft® Windows®-Betriebssystemen gehören, neben Leistung, Zuverlässigkeit und Verwaltbarkeit, zu den wesentlichen Aspekten bei der Betriebssystementwicklung. Um Bereitstellungskosten zu reduzieren und die Einführung zu beschleunigen, investiert Microsoft in die Entwicklung intelligenter technischer Lösungen, die die weitgehende Kompatibilität bestehender Software sicherstellen sollen. Der Frage der Kompatibilität wird somit bereits im Entwicklungs- und Freigabeprozess Rechnung getragen.

Die Anwendungskompatibilitätsinfrastruktur von Microsoft Windows (Shiminfrastruktur) ist eine dieser leistungsstarken technischen Lösungen. Mit der kontinuierlichen Weiterentwicklung von Windows, die das Ziel verfolgt, neue Technologien zu unterstützen, Bugfixes einzubinden und Strategieanpassungen zu implementieren, können Änderungen an der Implementierung einiger Funktionen verbunden sein, die sich auf darauf aufbauende Anwendungen auswirken. Erneute Funktionsänderungen zur Beseitigung dieser Kompatibilitätsprobleme könnten zu Störungen in anderen Anwendungen führen, oder es würde bedeuten, dass diese Windows-Funktion unverändert bleiben müsste – ungeachtet der Verbesserungen, die sich mit der neuen Implementierung erzielen ließen. Dies ließe sich umgehen, indem Verzweigungen direkt in den Quellcode von Windows implementiert würden, was im Hinblick auf Wartungsfreundlichkeit und Zuverlässigkeit des Betriebssystems jedoch beträchtliche Folgen hätte. Mithilfe der Shiminfrastruktur können Sie einen bestimmten Anwendungsfix, der für eine ganz bestimmte Anwendung (und oftmals auch nur für bestimmte Versionen dieser Anwendung) gilt, gezielt anwenden. Diese Fixes sind nicht Teil der Windows-Kernfunktionen und werden separat gepflegt.

Durch die Shiminfrastruktur wird eine Art API-Hooking (Application Programming Interface, Anwendungsprogrammierschnittstelle) implementiert. Genauer gesagt, die Infrastruktur nutzt die Besonderheiten von Bindungen, um API-Aufrufe von Windows zu alternativem Code, dem Shim, umzuleiten. Die Spezifikationen für Windows Portable Executable (PE) und Common Object File Format (COFF) umfassen mehrere Header. Über die Datenverzeichnisse in diesem Header wird zwischen der Anwendung und der gebundenen Datei eine Dereferenzierungsschicht bereitgestellt. Aufrufe an externe Binärdateien erfolgen über die Importadresstabelle (IAT). Ein Aufruf an Windows stellt sich für das System demzufolge wie in Abbildung 1 dar.

643f2bee-8329-4018-9d90-2ffcc7c76a6c

Abbildung 1   Anwendungsaufruf an Windows über die IAT

Konkret bedeutet das, dass Sie die Adresse der Windows-Funktion, die in der Importtabelle aufgelöst wird, ändern und durch einen Zeiger auf eine Funktion im alternativen Shimcode ersetzen können, wie in Abbildung 2 dargestellt ist.

Grafik

Abbildung 2   Anwendung, die vor dem Aufruf von Windows an den Shim umgeleitet wird

Diese Dereferenzierung erfolgt für statisch gebundene DLLs, wenn die Anwendung geladen wird. Sie können auch Shims für dynamisch gebundene DLLs verwenden, in dem Sie einen Hook zur GetProcAddress-API implementieren.

Implikationen des Aufbaus der Shiminfrastruktur

Wenn Sie eine Strategie für den Einsatz von Shims festlegen, können bestimmte Merkmale des Aufbaus der Shiminfrastruktur von Bedeutung sein.

1. Wie in Abbildung 2, "Anwendung, die vor dem Aufruf von Windows an den Shim umgeleitet wird", gezeigt wird, befindet sich der Code, der innerhalb eines Shims ausgeführt wird, außerhalb von Windows. Demzufolge gelten in Windows für Shimcode dieselben Sicherheitseinschränkungen wie für den eigentlichen Anwendungscode. Faktisch wird der Shimcode von Windows für Anwendungscode gehalten. Es ist daher nicht möglich, Shims zu verwenden, um in Windows integrierte Sicherheitsmechanismen zu umgehen. So ist beispielsweise kein Shim verfügbar, um die Eingabeaufforderungen der Benutzerkontensteuerung (User Account Control, UAC) zu umgehen und die Anwendung weiterhin mit erhöhten Berechtigungen auszuführen. Sie können einen Shim auf die Anwendung anwenden, damit keine Administratorrechte erforderlich sind, oder einen Shim anwenden, um diese Rechte als Voraussetzung festzulegen, aber um bei aktivierter UAC Administratorrechte zu erhalten, muss der Benutzer weiterhin die Rechteerweiterung genehmigen. Das gleiche gilt für selbst geschriebenen Code.

Wenn Sie die Auswirkungen des Einsatzes von Shims auf die Sicherheit der Unternehmensumgebung bewerten, können Sie somit davon ausgehen, dass durch Shims keine neuen Sicherheitslücken geöffnet werden. Ganz im Gegenteil: Die Verwendung von Shims, um die Lockerung von Sicherheitsbeschreibungen oder Sicherheitsrichtlinien zu vermeiden, ist in der Regel die sicherere Methode. Ohne Shims ist es Ihnen unter Umständen möglich, ein Kompatibilitätsproblem auszugleichen, indem Sie die ACLs für ein bestimmtes Verzeichnis lockern. Diese Entscheidung hat jedoch Auswirkungen auf das gesamte System. Mithilfe von Shims könnten Sie stattdessen den Dateizugriff für diese Anwendung zu einem benutzerspezifischen Speicherort umzuleiten. Ein weiteres Beispiel wäre eine Anwendung, die explizit das Vorhandensein von Administratorrechten prüft. Ohne Shims müssten Sie der Anwendung möglicherweise Administratorrechte zuweisen, damit diese Prüfung erfolgreich ist. Falls die Prüfung jedoch überflüssig ist, könnte ein Shim bei der Frage, ob der aktuelle Benutzer über Administratorrechte verfügt, einfach "lügen". In diesem Fall würde die Prüfung erfolgreich durchlaufen, ohne jedoch in der Sicherheitsinfrastruktur zusätzliche Angriffsflächen offenzulegen.

2. Da die Shiminfrastruktur – kurz ausgedrückt – zusätzlichen Code in die Anwendung einspeist, bevor ein Aufruf an Windows erfolgt, kann jeder Ausgleich, der mithilfe eines Shims erreicht werden kann, auch durch eine Änderung des Anwendungscodes selbst erfolgen. Zumindest wäre es möglich, dass die Anwendung Code enthält, der dem Code ähnelt, den Windows mit dem Shim implementiert, bevor ein Aufruf an eine Windows-API erfolgt.

3. Da Shims als Benutzermoduscode innerhalb eines Benutzermodus-Anwendungsprozesses ausgeführt wird, ist es nicht möglich, einen Shim zu verwenden, um Kernelmoduscode zu korrigieren. Es ist beispielsweise nicht möglich, Shims zu verwenden, um Kompatibilitätsprobleme mit Gerätetreibern oder anderem Kernelmoduscode zu beheben. (Code von einigen Antiviren-, Firewall- und Antispywareanwendungen wird beispielsweise im Kernelmodus ausgeführt.)

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft