Autor: Andr\u00e9 Schmitz, Green Hills Software<\/p>\n
Die gr\u00f6\u00dften Schwachstellen eines Software-Systems sind meist die Ger\u00e4tetreiber. Sie k\u00f6nnen oft auf alle Hardware-Register und den DMA-Controller zugreifen, laufen im Supervisor-Mode der CPU und haben den ersten Kontakt mit den von au\u00dfen kommenden Daten. Nicht zuletzt ist dies der Grund daf\u00fcr, dass viele Verwundbarkeiten und Absturzursachen von Software in den Treibern zu finden sind. Dieser Beitrag zeigt Methoden und Technologien mit denen Ger\u00e4tetreiber „sicher“ gemacht werden k\u00f6nnen, das hei\u00dft, die Auswirkung eines Angriff auf die Treiber oder einer Fehlfunktion durch Softwarefehler kann minimiert und damit die Robustheit des Gesamtsystems verbessert werden.<\/strong><\/p>\n Ich gehe davon aus, dass die meisten Leser wissen, was ein Treiber ist. Trotzdem m\u00f6chte ich die wichtigsten Aspekte kurz zusammenfassen. Ein Ger\u00e4tetreiber ist die Softwarekomponente, die direkten Zugriff auf die Hardware hat und der Applikation eine Abstraktion in Form eines Hardware-unabh\u00e4ngigen Interfaces (API) darstellt [1]. Als solches kann ein Treiber sowohl Ereignisse (Interrupts) zur Anwendung signalisieren als auch Daten zwischen Anwendung und Hardware \u00fcbertragen. Dies kann dann zum Beispiel auch unter Verwendung eines DMA- oder PCI-Controllers geschehen.<\/p>\n Hin und wieder werden auch Protokoll-Stacks, wie z.B. TCP\/IP oder USB-Host-Stack, als Treiberkomponenten betrachtet. Man kann sich dar\u00fcber streiten, ob es sich hier um Treiber oder eher um Target-unabh\u00e4ngige „Middleware“ handelt, die eng mit einem Treiber zusammenarbeitet. Die \u00dcberlegungen in diesem Papier finden jedoch ebenso Anwendung auf diese Stacks.<\/p>\n In einfachen Embedded-Systemen kann ein Treiber sehr einfach sein und z.B. nur ein paar GPIOs aktivieren oder ein Relais steuern. Einfache eventgesteuerte Ereignisse k\u00f6nnen sogar direkt im Interrupt-Handler bearbeitet werden. F\u00fcr komplexere Operationen bedarf es mehr Code, der dann zum Beispiel in einer oder mehreren Tasks abl\u00e4uft. Der Code dieser Tasks greift dann direkt auf die Hardware zu und stellt den h\u00f6heren Softwareschichten ein abstraktes Interface zur Hardware zur Verf\u00fcgung.<\/p>\n Nahezu alle Daten, die ein Embedded-System bearbeitet, wandern durch einen Treiber wenn sie die Grenzen des Systems passieren. Treiber laufen au\u00dferdem oft im privilegierten Modus der CPU, damit sie direkt auf die Hardwareregister und den Speicher zugreifen k\u00f6nnen. In diesem Fall kann der Treiber aber auch auf anderen Speicher oder andere Register zugriefen, die nichts mit seiner eigentlichen Aufgabe zu tun haben. Egal, ob gewollt oder ungewollt besteht die M\u00f6glichkeit, dass ein Ger\u00e4tetreiber auf beliebige andere Ger\u00e4te zugreift oder beliebigen Speicher manipuliert. Dies verleiht dem Treiber einen gro\u00dfen Einfluss auf die Zuverl\u00e4ssig\u00adkeit und Sicherheit des Gesamtsystems.<\/p>\n Eine Fehlfunktion des Treibers kann dazu f\u00fchren, dass die Daten unerlaubt ver\u00e4ndert werden (Integrit\u00e4t). Ein Softwarefehler kann das System zum Absturz bringen (Zuverl\u00e4ssigkeit) oder einem potentiellen Angreifer Zugriff auf vertrauliche Daten geben (Vertraulichkeit). Letztlich sind die Treiber daher eine vitale Komponente des Gesamtsystems.<\/p>\n Wenn Treiber nahe am Betriebssystem arbeiten oder direkt auf Hardware zugreifen k\u00f6nnen, dann k\u00f6nnen Fehlfunktionen gravierende Auswirkungen haben. Eine Fehlfunktion im Treibercode im Supervisor-Mode der CPU (Abbildung 1, siehe\u00a0PDF<\/a>) kann das gesamte System zum Absturz bringen. Eine Schwachstelle in diesem Code kann einem Angreifer erlauben, die Kontrolle \u00fcber das gesamte System zu erlangen. Selbst ein virtueller Treiber, der im User-Mode l\u00e4uft (Abbildung 2, siehe\u00a0PDF<\/a>), kann ein Problem darstellen, wenn der Prozess zu viele Rechte erh\u00e4lt.<\/p>\n Wenn es um Angriffsszenarien geht, dann findet man Puffer-\u00dcberl\u00e4ufe als h\u00e4ufigsten Grund f\u00fcr Verwundbarkeiten von Software. Sucht man in der Vulnerability Notes Database nach den kritischsten Verwund\u00adbar\u00adkeiten in Software, dann findet man bei mehr als der H\u00e4lfte der gemeldeten Verwundbarkeiten einen Puffer-\u00dcberlauf als Ursache [2].<\/p>\n Die potentiellen Gefahren eines Treibers kann man einschr\u00e4nken, indem man sich die Prinzipien des High Assurance Software Engineering zunutze macht. Diese Prinzipien umfassen Themen wie<\/p>\n Speziell zum Schutz gegen die ber\u00fcchtigten Puffer-\u00dcberl\u00e4ufe gibt es M\u00f6glichkeiten, die gef\u00e4hrdeten Stellen in der Software mithilfe von statischer Codeanalyse zu finden (Entwicklungsprozess). Falls diese noch nicht alle Stellen findet, kann man mit einem geeigneten Compiler automatische Laufzeit-Checks in den Code einbauen lassen, die diese \u00dcberl\u00e4ufe sogar w\u00e4hrend der Ausf\u00fchrung des Codes erkennen k\u00f6nnen und den Ablauf des Programms dann unterbrechen. Dies ist w\u00e4hrend der Entwicklung sehr hilfreich, kann aber auch im produktiven System verwendet werden.<\/p>\n Die Punkte 1 und 2 kann man besonders gut mithilfe eines Micro-Kernels adressie\u00adren. Die Verwendung eines Micro-Kernels, oder eher noch eines Separation-Kernels, erlaubt es, die Treiber im User-Mode auszuf\u00fchren (minimale Rechte) und einzelne Treiber separiert voneinander und separiert von der Applikation laufen zu lassen (Unterteilung in Komponenten). Dies ist dann ein sogenannter „User-Mode-Treiber“. In einem gut strukturierten System basierend auf einem Separation-Kernel erh\u00e4lt ein User-Mode-Treiber nur Zugriff auf die Hardwarekomponenten, die er f\u00fcr seine korrekte Funktion wirklich braucht, d.h. er „sieht“ nur die Register des von ihm zu steuernden Hardwaremoduls (Abbildung 2, siehe\u00a0PDF<\/a>). Auch bekommt er nur Zugriff auf die Speicher\u00adbereiche, die er f\u00fcr seine Arbeit tats\u00e4chlich ben\u00f6tigt, und auf keine anderen. Zum Beispiel sieht der Display-Controller nur den Frame-Buffer im RAM sowie die Konfigurationsregister des Controllers, oder der Ethernet-Treiber sieht nur den Bereich mit den Speicher f\u00fcr die Ethernet-Puffer und deren Deskriptoren.<\/p>\n Sehr spannend wird die Sache aber zum Beispiel beim Zugriff auf einen DMA-Controller, dessen Verwendung aus Performancesicht sinnvoll sein kann. Kritisch wird der Zugriff in einem Microkernel dann, wenn der User-Mode-Treiber direkt den DMA-Controller konfigurieren kann. In diesem Fall hat der Treiber n\u00e4mlich die M\u00f6glichkeit, jeden beliebigen Speicher zu adressieren und von dort zu lesen oder dorthin zu schreiben. Und wenn dieser Treiber dann gehackt wird und der Angreifer die Kontrolle \u00fcber den Treiber-Prozess erh\u00e4lt, dann hat der Angreifer auch wieder Kontrolle \u00fcber das Gesamtsystem, weil er mittels DMA-Controller auf jeden Speicher zugreifen kann. Aber genau das will man ja eigentlich mit einem User-Mode-Treiber auf einem Microkernel vermeiden.<\/p>\n Man muss sich dann mit Punkt 4 helfen, indem man alle Treiber, die auf den DMA-Controller zugreifen, nach einem sicheren Entwicklungsprozess entwickelt, so dass der Treibercode eine hohe Vertrauensw\u00fcrdigkeit hat. Alternativ kann man sich aber auch viel Aufwand sparen, indem man einen Microkernel verwendet, der es doch erlaubt, kleine, vertrauensw\u00fcrdige Fragmente eines Treibers im privilegierten Modus der CPU laufen zu lassen, also direkt neben dem Kernel (Abbildung 2, links, siehe\u00a0PDF<\/a>). Nat\u00fcrlich muss in diesem Fall der Treiber auch sehr gut validiert sein (Entwicklungs\u00adprozess), aber da es sich hier um sehr wenig und sehr einfachen Code handelt (Minimierung der Komplexit\u00e4t), ist der damit verbundene Aufwand deutlich kleiner als der f\u00fcr den DMA-Treiber im User-Mode.<\/p>\n Wie oben beschrieben k\u00f6nnen schlecht designte oder un\u00fcberlegt programmierte Ger\u00e4tetreiber ein Embedded-System angreifbar machen oder sogar zum Absturz bringen. Sie bieten eine gro\u00dfe Angriffsfl\u00e4che und haben oft sehr viele Privilegien, die einem Softwarefehler ein hohes Wirkpotential geben. Die Verwendung der Grundprinzipien des High Assurance Software Engineering kann dieses Problem extrem verkleinern. Dazu geh\u00f6rt nicht zuletzt die Verwendung eines Separation-Kernels, bei dem User-Mode-Treiber verwendet werden, der es aber auch erlaubt, vertrauensw\u00fcrdigen Treibercode im Kernel-Mode auszuf\u00fchren, falls dies sinnvoll ist.<\/p>\n [1]\u00a0https:\/\/de.wikipedia.org\/wiki\/Ger\u00e4tetreiber<\/a><\/p>\n [2]\u00a0https:\/\/www.kb.cert.org\/vuls\/bymetric?open&start=1&count=20<\/a><\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Implementierung \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Implementierung\/\u00a0Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nWas ist ein Treiber<\/h2>\n
Warum sind Treiber kritische Komponenten von Software<\/h2>\n
Methoden zum Schutz<\/h2>\n
\n
Microkernel<\/h2>\n
DMA<\/h2>\n
Zusammenfassung<\/h2>\n
Referenzen<\/h2>\n
\nImplementierung – unsere Trainings & Coachings<\/h2>\n
\nImplementierung – Fachwissen<\/h2>\n