Dipl.-Inform. Carsten Eilers

Microsoft liefert mit Windows eine Datenbank mit Shims aus, um bekannte Kompatibilitätsprobleme zu korrigieren. Anwender können diese Shims mit Hilfe des Application Compatibility Toolkit problemlos einsetzen, wenn sie auf ein Programm angewiesen sind, das vom Hersteller nicht mehr unterstützt und deshalb nicht an eine neue Windows-Version angepasst wird. Oder wenn sie die Zeit bis zur Veröffentlichung einer kompatiblen Programmversion überbrücken müssen. Auch wenn es dann oft einfacher sein wird, mit der Installation der neuen Windows-Version entsprechend zu warten.

Für Entwickler sind Shims aber oft überflüssig. Denn über die Shim-Infrastruktur wird nur Code in das fertige Programm eingefügt, der vor dem Aufruf der Windows-APIs ausgeführt wird. Jedes Problem, dass über ein Shim behoben werden kann, kann vom Entwickler also auch direkt im Code seines Programms behoben werden. Im einfachsten Fall reicht es, die vom Shim-Code durchgeführten Änderungen an den API-Aufrufen etc. vom Programm selbst ausführen zu lassen. Zukunftssicherer ist natürlich die direkte Anpassung der API-Aufrufe etc. an das neue System (bzw. das neue API).

... aber nicht immer

Aber auch für Entwickler kann die Nutzung eines Shims nötig werden, zum Beispiel weil ein Programm mit den vorhandenen Ressourcen nicht rechtzeitig an eine neue Windows-Version angepasst werden kann. Werden dann, soweit möglich, Shims verwendet, bleiben mehr Ressourcen für die Korrektur der nicht über ein Shim korrigierbaren Inkompatibilitäten. Allerdings sollte man sich dann schon fragen, was denn da wohl schief gelaufen ist, denn neue Windows-Versionen erscheinen ja nun wirklich nicht von heute auf morgen und ohne jede Vorwarnung.

Jetzt wird es unschön...

Shims sind also durchaus nützlich, aus Sicherheitssicht natürlich besonders beim Einsatz im Rahmen von Workarounds. Leider haben Sicherheitsforscher aber auch Nachteile der Shims entdeckt.

Schon 2012 gab es im Blog von Recx (Research, Develop, Assess, Consult & Educate) zwei Artikel zur Sicherheit von Shims. Dabei wird unter anderen auf die Möglichkeit hingewiesen, einen "Fault tolerant heap" zu verwenden, der viele Fehler verzeiht und dazu auf all die schönen Sicherheitsfeatures verzichtet. Was nicht anderes bedeutet, als dass es Programme gibt (bzw. inzwischen hoffentlich: gab), die ihren Heap nicht so benutzen können, wie es von Windows Vista und seinen Nachfolgern eigentlich gefordert wird. Wenn man bedenkt, dass Microsoft in Windows Vista und seinen Nachfolgern immer mehr und bessere Schutzmaßnahmen gegen Angriffe über Heap-basierte Pufferüberläufe implementiert hat, ist es doch sehr beunruhigend, wenn es einen offiziellen Weg gibt, diesen Schutz auszuschalten.

Aber das ist noch nicht das Schlimmste, denn Sie wissen ja: Schlimmer geht immer. Zum Beispiel, wenn die Angreifer die FixIt-Patches missbrauchen.

FixIt-Patches in Angreiferhand, erst mal "nur" zum Verstecken

Auf der Derbycon 2013 hat Mark Baggett demonstriert, wie Angreifer ein Rootkit mit Windows-Bordmitteln implementieren können, darunter dem Microsoft Application Compatibility Toolkit und seinen Shims. Der Titel seines Vortrags ist identisch mit dem zu ziehenden Fazit daraus: "Windows is 0wned by Default!". Das ACT nutzt er dabei zum einen zum Verstecken des Rootkits, zum anderen um dessen Persistenz zu erreichen. Dafür muss das Rootkit aber zuvor Administrator-Rechte erlangt haben. Aber das haben Rootkits ja generell so an sich.

Leider lässt sich mit den Shims aber noch mehr Schaden anrichten, was sowohl in der Theorie als auch der Praxis bewiesen wurde. Darum geht es in der nächsten Folge.

Carsten Eilers