Usermode böse - Kernelmode lieb! Treiber sinnvoll einsetzen.

[Olli]

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 ...

[alcaeus]

Netter Artikel, auch wenn der Titel jedenfalls fuer den Laien (mich ) strange erscheint; es scheint so als wuerdest du sagen dass der Kernelmode lieb, und der Usermode boese ist

Greetz
alcaeus

[turboPASCAL]

Mal was interesanntes, wieder was gelernt.

[Robert Marquardt]

Gemeinerweise dokumentiert MS aber nicht welche MS-Treiber ihre Parameter testen und welche nicht.
Einige Treiber die nur zur Benutzung durch andere Treiber vorgesehen sind (namentlich HIDUSB.SYS) machen das naemlich nicht.

[Olli]

Zitat von Robert Marquardt:

Gemeinerweise dokumentiert MS aber nicht welche MS-Treiber ihre Parameter testen und welche nicht.
Einige Treiber die nur zur Benutzung durch andere Treiber vorgesehen sind (namentlich HIDUSB.SYS) machen das naemlich nicht.

Das stimmt. Besonders bei USB gibt es auch seitens der Treiberprogrammierer viel böses Blut. Da hat Microsoft sich einige Schnitzer erlaubt ...

... aber alles wird gut - mit Vista

[SirThornberry]

Supi geschrieben. Immer wenn jetzt wieder so ein Thread auftaucht wo nach Treiberprogrammierung mit Delphi oder ähnliches gefragt wird kann man jetzt erstmal die URL dieses Artikels posten...

[richard_boderich]

äh du meinst jetzt aber nicht sowas wie z.b die portio.sys oder portio.dll treiber, den diese
ermoeglichen ja auch direkten zugriff auf speicheradressen ueber den smbus? ich frage naehmlich weil
ich diese komponenten in meiner mainboardueberwachungssaftware benutze.

gruß richard

[brechi]

Hab nichts gegen den Artikel auszusetzen.
Alles was ich so programmiere, ist halt rein proof of concept, womit ich zeige, was man alles so machen kann. z.b. werden aber Usermode hooks wirklich eingesetzt und komerziell verkauft, (madshi.net) wo ich mir ebenfalls super oft denken muss wie wenig Plan die Nutzer davon haben wenn sie meinen sie köntnen damit Antiviren-Programme schreiben.
Generell gebe ich gerne meine Sourcen weiter. (will sie ja nicht nur umsonst für mich für ein kleines Testprogramm geschrieben haben)
Zumal es in letzter Zeit viele Leute (Skriptkiddies??) gibt die mal in deim ein oder anderen Programm etwas hooken wollen oder eben einen Trainer schreiben wollen. Dafür sind meine Sourcen halt schon nützlich, denn wer hat immer Bock sich damit selbst zu verfassen, weil es doch recht kompliziert ist.

Und wie auch alle wissen, darf man meinen Sourcecode eben nicht in komerziellen Anwendungen benutzen, weil hooking so wie ich es mache eben eigentlich total unsicher ist. Sei es im User wie auch im Kernelmode.
Aber man kann immer so schöne Sachen damit machen, wenn man gerade dem ein oder anderen Programm wieder was vortäuschen muss

[jfheins]

Zitat von Olli:

Generischer Portzugriff ist was Feines ...

... sagte der Virus und brannte lustige Muster auf dem CRT-Monitor ein.

Das hört sich erstmal lustig (bzw. für die Eigentümer unzeitgemäßer ( ) CRT's traurig) an ... aber mir stellt sich jetzt die Frage, was denn "generischer" Zugriff ist, was man damit machten kann(, und wie man ihn erreicht) ...

// Ansonsten finde ich den Artikel super

[Kidi]

Hallo zusammen.
Was soll ich noch großartig zu diesem Artikel sagen bis auf klasse geschrieben und meine Hochachtung dazu.
Mfg