Weil (mir) das Thema immer wieder hochkommt, wenn Leute fragen wie man dies oder jenes machen kann, wollte ich mal ein paar klarstellende Worte zum Sinn und Unsinn der Trennung von Kernel- und Usermode verlieren.


Vom Usermode in den Kernelmode

Zuallererst möchte ich natürlich Brechi und seinen Kollegen Respekt zollen. Natürlich kann man einen Treiber prinzipiell auch mithilfe des Delphi-Compilers und -Linkers zusammenbasteln; natürlich kann man über andere Wege (z.B. PhysicalMemory-Section) in den Kernelmode eindringen. Alles ganz doll und auch sehr imposant. Aber leider alles nur für Hackertools tauglich. Ja, richtig gelesen, Hackertools: diese Lösungen sind nichts für den Ottonormalprogrammierer, geschweige denn -anwender, der u.U. nichtmal genau weiß was Kernelmode und was Usermode sind. Und man möge mir verzeihen wenn es pedantisch klingt, aber die kleinen nützlichen, "nützlichen" und unnützen Code-Schnipsel, die irgendwann mal entstehen machen es leider noch zu häufig in eine später kommerzielle Lösung. Das ist dann fatal, wenn weder der Programmierer weiß was er tut, noch der Benutzer die Sicherheitslöcher erahnt, die durch die Installation einer solchen Software aufgetan werden.


Begrifflichkeiten und Befindlichkeiten

Die Begriffe Kernelmode (KM) und Usermode (UM) werden oft sehr abstrakt verwendet. Komischerweise haben sie aber einen Sinn. Dieser besteht hauptsächlich darin, daß eine Trennung von privilegiertem und unprivilegiertem Code erzeugt wird. Diese Trennung ist wichtig, weil man sonst auf der NT-Plattform noch immer diese wundervollen Bluescreens en masse wie unter Win9x bekäme.
Falls jetzt jemand meint, er hätte unter NT aber auch schonmal einen Bluescreen gesehen - erstmal Luft anhalten.

Diese Trennung der Modi wird dank des Prozessors direkt unterstützt und ermöglicht beispielsweise, daß die Prozesse auf der NT-Plattform strikt voneinander getrennt sind. Ansonsten könnte eben einer beim anderen im Adreßraum rumkritzeln. Nicht sonderlich prickelnd wenn das eigene Programm Opfer von sowas wird.

Jeder KM-Programmierer lernt so ziemlich als erstes, daß UM-Code böse ist. Dies hat einen gewissen Sinn; es schärft dem Programmierer ein, keinem UM-Code zu trauen. Wenn der UM-Code also einen Request an einen Treiber schickt und darin steht, daß Adresse XYZ "gut" ist, muß der Treiber dennoch, so paranoid es erscheinen mag, penibelst prüfen ob der UM-Code auch wirklich nicht "lügt". Alles andere kann, von einem BSOD (Bluescreen of death) über Hardwareschäden bis zu schlimmsten Sicherheitslücken, bittere Konsequenzen nach sich ziehen.

Interessanterweise ist der erste Schrei seitens der Anwender, wenn Windows mal wieder blaumacht, "Windows ist schuld!". Obwohl das natürlich der Fall sein kann, ist es keineswegs so wahrscheinlich wie daß es sich um einen Treiber eines Drittanbieters handelt. Natürlich kann es vorkommen, daß Microsoft "vergessen" hat bei einer Funktion auf ungültige Parameter zu prüfen. Dies ist aber sehr unwahrscheinlich und, wie ich hier (ab #28) nachgewiesen habe, zumeist auf Software von Drittanbietern zurückzuführen. Das ist eben der große Unterschied zwischen UM- und KM-Programmierung: wenn ich im UM scheiße programmiere, stürzt maximal mein Programm (oder im Fall von Hooking-DLLs alle gehookten Programme) ab, wenn ich im KM scheiße programmiere, stürzt im besten Fall nur der PC mit einem BSOD ab - im schlechtesten Fall beschädige ich gleich noch die Hardware.

Vielleicht lassen die obigen Ausführungen den einen oder anderen schon erschaudern, wenn sie daran denken was bei falscher Handhabung alles passieren kann, aber es kommt noch besser.

Generischer Portzugriff ist was Feines ...

... sagte der Virus und brannte lustige Muster auf dem CRT-Monitor ein. Zugegeben, dank TFTs ist dieses Risiko gemindert, aber das Umprogrammieren von Hardwarekomponenten ist nach wie vor möglich.

In allen diesen Fällen ist es natürlich so, daß die Hardware spezifisch angesprochen und zerstört werden muß. Aber auch wenn es nur 50% der Anwender trifft, dürfte das für ein Softwarehaus (jenes welches den Zugriff ermöglichte) einen beträchtlichen Imageschaden bedeuten.

"Lustig" wäre auch die Umprogrammierung von Dongles, denn da gibt es nicht so viele verschiedene Systeme, daß man sie nicht bequem in einem Trojaner unterbringen könnte. So wäre gleichzeitig die Firma welche die Dongles produziert, die Firma welche die Dongles benutzt um ihre Software zu schützen und nicht zuletzt der Kunde sprichwörtlich angeschissen.

Immer wieder werden, sei es aus Unwissenheit oder Ignoranz, Lösungen empfohlen, die generischen Portzugriff erlauben. Diese empfinden die CPU-Befehle IN und OUT nach. Die korrekte Alternative wäre allerdings ein Treiber, welcher nur auf spezifische Ports einen Zugriff erlaubt. Absichern kann man sich nämlich nicht gegen feindliche Übernahme. Deswegen kann der Treiber genau wie er vom eigenen Programm benutzt werden kann auch von einem fremden Programm (z.B. einem Virus) mißbraucht werden. Generisch bleibt generisch, und so ist dann auch die potentielle Schadenswirkung: breitmöglichst.


Fazit

Wer nach diesen Ausführungen noch nicht kapiert hat, wohin es führen kann - und mittelfristig wird - einem Usermode-Programm generischen Zugriff auf Ressourcen zu geben, die eigentlich dem Kernelmode vorbehalten bleiben sollten, der wird es sicher niemals begreifen, oder er tut es eben aus Spaß an der Hackerei. Allerdings ist Hackerei selten alltagstauglich, weshalb auch die Fragesteller sich nicht immer auf den erstbesten "Rat" zur Einschleusung von Code in den KM oder zur Benutzung von generischem Portzugriff einlassen sollten. Im Endeffekt hat die Trennung nämlich seinen Sinn gehabt und Microsoft/Cutler hat sich was dabei gedacht.

Beklagen müssen wir uns jedenfalls nicht darüber, daß Windows so instabil ist, sondern daß wir es so instabil machen indem wir solche Frickellösungen zulassen und vielleicht noch weiterempfehlen.


So das war's. Ich hoffe es hat meinen Lesern ein wenig Einsicht gebracht. Da solche Diskussionen seit Jahren immer wiederkehren, dachte ich mir es sei Zeit für eine kleine Abhandlung zum Thema ...