Von Dipl. Ing. Frank Gerlach, frankgerlach.tai@gmx.de
Populäre Makrokernel wie Linux, Windows, MacOS, AIX, HP-UX, Solaris, z/OS, FreeBSD, NetBSD sind in nicht speichersicheren Sprachen wie C, Assembler und PL/S implementiert. Der Umfang dieser Kernel liegt im Bereich von Millionen Zeilen Quellcode. Ein einziger Programmierfehler ermöglicht typischerweise die vollständige Übernahme (Definition siehe unten) des Rechners durch einen kybernetischen Gegner.
Mikrokernel wie seL4, QNX oder Integrity 178 haben dagegen einen minimalen Umfang im Bereich von wenigen 10000 Zeilen Quellcode. Sie sind damit formal/mathematisch als korrekt beweisbar. Ein Programmierfehler in einem Modul(z.B. TCP Stack, Wifi Stack, Bluetooth Stack) führt in der Regel nur zum Ausfall dieses Moduls, nicht aber zu einem Total-Übernahme des Rechners.
Linux: Ein Treffer(Exploit) in X11, USB, Bluetooth, ext3 oder TCP/IP versenkt das Schiff
seL4: Ein Treffer in einer Abteilung führt nur zu einer Fähigkeitsverminderung, versenkt das Schiff aber nicht
Mikrokernel wie seL4 können in weniger als 20000 Zeilen Programmcode realisiert werden und sind damit in überschaubarer Zeit als korrekt beweisbar. Im Gegensatz dazu haben die Makrokernel Linux, Windows, FreeBSD, OpenBSD, MacOS eine Angriffsfläche im Bereich von mehreren Millionen Zeilen Programmcode. Eine einzige Schwäche in einem C- oder C++-basierten Makrokernel ermöglicht in den meisten Fällen die vollständige Übernahme des Rechners. Der Angreifer kann in diesem Fall alle Daten auslesen und manipulieren.
Sollte in einem Mikrokernel-Subsystem (z.B. TCP Stack, CAN Stack oder Bluetooth Stack) eine ausnutzbare Sicherheitslücke auftreten, so begrenzt sich die Wirkung auf dieses Subsystem. Insbesondere sind vertrauliche oder geheime Daten der Applikationsebene typischerweise nicht betroffen, da sie von der Applikation oder von einem eigenen Chiffrierprozess verschlüsselt werden, bevor sie diesen Kommunikations-Subsystemen übergeben werden. Als erste Notmaßnahme werden in diesem Fall die Firewall-Regeln drastisch verschärft und danach das Subsystem neu gestartet.
Im Falle industrieller Steuerungssysteme wird eine ausnutzbare Sicherheitslücke in den Kommunikations-Subsystemen das Prozessregelsystem in einem anderen Prozess nicht unmittelbar betreffen. Ein ordentlich entwickeltes System wird sich dann automatisch in einen Notlauf oder die Abschaltung begeben.
Bei militärischen Wirkystemen ist ebenso von "sicherer Abschaltung" auszugehen, wenn die genannten Subsysteme ausfallen.
Im Falle eines Geldautomaten ist mit einem Ausfall des Automaten ohne Ausgabe von Bargeld zu rechnen. Damit entfällt für einen potenziellen Angreifer das Interesse für einen Angriff auf die Kommunikations-Subsysteme. Die Bank wird einfach das System neu starten, ohne dass ein größerer Verlust entsteht.
Ein technologisch anderer Ansatz ist es, den Kernel in einer speichersicheren Sprache zu realisieren. Damit lassen sich zumindest die Speicherfehler, welche 70% aller CVE- Exploits darstellen, in der Regel neutralisieren. Beispiele dafür sind