-
Im Folgenden wird das zur Patentierung angemeldete Verfahren beschrieben. Es ist bisher
kein Verfahren bekannt, daß dazu fähig ist die strikten Regeln des Ansatzes einer Positivliste
auf Betriebssystemebene umzusetzen. Die unterschiedlich eingereichten Dokumente aus
dem DEPATISnet sind kein Bestandteil der Patenanmeldung, sondern zeigen erteilte
Patente, die diesem Verfahren am nächsten kommen. Sie dienen lediglich als Beleg, daß das
hier beschriebene Verfahren nie Bestandteil einer vorhergehenden Patentanmeldung war.
Definition Positivliste alias Whitelist
-
Die Positivliste folgt dem Ansatz der neuesten Entwicklung bei regelbasierten
Sicherheitsumgebungen. Grundsätzlich wird der gesamte auf einem Computersystem
verfügbare Programmcode als schädlich angesehen. Programme haben vor dem
Betriebsystem die Beweispflicht, unbedenkliche Befehle zu enthalten. Der gesamte
ausführbare Abschnitt einer Programmdatei muß beim Betriebssystem registriert werden. Die
Registrierung erfolgt über Hashwerte, die aus der betreffenden Programmdatei abgeleitet und
symbolisch für das Programm beim Betriebssystem registriert werden. Das Betriebsystem
kann zur Laufzeit den Hashwert einer beliebigen Programmdatei bestimmen und mit dem
registrierten Wert vergleichen. Nur bei erfolgreichen Vergleichen wird eine Programmdatei
akzeptiert.
Definition kollisionsfreier Hashalgorithmus
-
Die Checksummen der Programmdateien werden über eine stark kollisionsfreie Hashfunktion
errechnet. Charakteristisch für diese Funktionen sind möglichst große Bitunterschiede im
Hashergebnis selbst bei geringen Unterschieden in der Quelldatei. Es soll für einen Angreifer
unmöglich sein, eine funktionsfähige Programmdatei zu erstellen, die ein identisches
Hashergebnis wie eine bereits registrierte Programmdatei hat. Stark kollisionsfreie
Hashfunktionen erfüllen diese Vorgaben durch die Verwendung geeigneter mathematischer
Algorithmen.
-
Erfahrungen zeigen, das eine Hashlänge von 128 Bit ausreichend ist. Bei dieser Hashlänge
konnten bisher keine künstlich herbeigeführten Kollisionen von Hashwerten erzeugt werden.
-
Zu den Algorithmen der Klasse der stark kollisionsfreien Hashfunktionen gehören unter
anderem SHA1, MD4, MD5 und RIPEMD.
Beschreibung des Betriebssystemverhaltens bei der Ausführung von Prozessen
-
Die Ausführung einer Programmdatei läuft auf allen etablierten Multiprogramming-
Betriebsystemen identisch ab. Einem Kommandointerpreter wird vom Benutzer bzw. vom
System mitgeteilt, welche Programmdatei ausgeführt werden soll. Der Kommandointerpreter
löst einen Systemruf beim Betriebsystemkern aus. Über einen Software-Interrupt oder ein
Syscall-Makro wird ein Übergang in den Speicherbereich des Betriebssystemkerns
erzwungen. Der Betriebsystemkern hat nun dies Aufgabe einen Prozeß zu erzeugen, die
Ausführungsdomäne vorzubereiten, den Speicher zu reservieren und die Programmdatei zu
laden. An diesem Punkt greift das zur Patentierung vorliegende Verfahren ein. Von der
Programmdatei wird beim Laden ein Hashwert erzeugt und mit den registrierten Werten
verglichen. Ist ein Vergleich positiv, wird die Prozeßerstellung abgeschlossen, ansonsten wird
die Prozeßerstellung abgebrochen und eine gültige Fehlermeldung zurückgegeben. Auf
Multiuser-Betriebsystemen wird im Systemlog der fehlgeschlagene Versuch mit Zeitstempel,
Dateiname, errechnetem und registriertem Hashwert eingetragen.
Speicherung der Positivliste
-
Um mißbräuchliche Veränderungen der registrierten Hashwerte vorzubeugen, wurden diese in
einer Speicherstruktur des Kernels abgelegt. Der Zugriff kann über Schnittstellen des
Betriebssystems gesteuert werden und verwehrt im Extremfall selbst Systemverwaltern die
Möglichkeit zur Registrierung von Programmdateien.
-
Beschreibung Kernel Memory, Read-Once-Mechanismus
Formulierung des Patentanspruchs
-
Wir begründen unseren Patenanspruch auf ein in ein beliebiges Betriebsystem integrierbares
Verfahren zur Überprüfung von Prozessen zur Laufzeit mit einer Positivliste. Zum jetzigen
Zeitpunkt sind keine Konzepte bekannt, die einen derart restriktiven Schutz auf
Betriebssystemebene beschreiben, somit stellt dieses Verfahren eine Neuentwicklung bei
der Absicherung von Rechnersystemen dar. Als Proof-Of-Concept wurde das Verfahren auf
Basis des Betriebsystems LINUX implementiert und in den Ihnen vorliegenden Unterlagen
unter Punkt 4 beschrieben.
1. Ausgangssituation
-
Die Nachteile und Schwächen in Punkto Sicherheit aller herkömmlichen
Betriebssysteme beruht auf deren Starrheit und Technik im Umgang mit
Programmen und Skripten. Dieses betrifft im besonderen Maße die
folgenden Punkte:
- - Virenerkennungssoftware funktioniert nur für bekannte Viren.
Spezielle Makroviren und andere werden teilweise anhand
bestimmter, bekannter Funktionen erkannt. Diese Erkennung bietet
keine absolute Sicherheit, da sie reaktiv ist und mit neuen
Angriffsszenarien für die sie nicht programmiert sind, nicht
fertig werden.
- - Spähprogramme bzw. Trojanische Pferde können teilweise gar nicht
erkannt werden. Das Einschleusen solcher Programme ist selbst von
herkömmlichen Sicherheitseinrichtungen wie Firewalls und
Virenerkennungsprogrammen nicht auszuschließen. Besonders hervorzuheben
ist die Möglichkeit, Programmteile in dynamische Bibliotheken
einzuschleusen, wodurch schädliche Funktionen durch jedes Programm
ausgelöst werden kann.
- - Werden Teile des Betriebssystems selbst infiziert, können so alle
herkömmlichen Sicherheitstechniken unterlaufen werden.
-
Die traditionellen Angriffe auf Computersysteme beziehen sich auf
zwei bevorzugte Techniken:
- - Fehler in Programmen ausnutzen um sie zum Absturz zu bringen und
auf der Betriebssystemebene schädliche Funktionen auszuführen.
- - Passwörter herausfinden (Diese Art Angriff ist praktisch nicht
auszuschließen, da sie den Menschen involviert)
-
Die herkömmlichen Sicherheitssysteme auf Servern sind aufwendig in
der Administration und eingeschränkt in der Wartbarkeit,
Bedienbarkeit und Leistung.
-
Bei geschlossenen Betriebssystemen, wie z. B. Mircosoft, Novell etc.
kann nicht herausgefunden werden, welche Funktionen oder
Spionageteile diese schon ab Werk eingebaut haben.
-
Um die oben genannten Nachteile der gängigen Betriebssysteme zu
umgehen, wurde ein Verfahren entwickelt, das im weiteren beschrieben
wird.
2. Zielsetzung/Aufgabe
-
Der Grundgedanke ist, unter Einbezug des Open Source Betriebssystems
Linux, einen Hochsicherheits-Server (HSS) zu erstellen. Der HSS
verfügt über folgende Eigenschaften:
- - Schnelle Betriebsbereitschaft/kurze Ausfallzeiten
- - Bietet in Netzwerken eine minimale Angriffsfläche
- - Beinhaltet keine verdeckten Softwarekomponenten
- - Ist immun gegen Viren
- - Ist immun gegen Trojanische Pferde/Spähprogramme
3. Lösung
3.1. Zwangs-Booten von CD-ROM
-
Das komplette Betriebssystem befindet sich auf einer CD-ROM. Von
dieser wird das System gestartet. Der Kernel des Betriebssystems
befindet sich niemals auf einem beschreibbaren Medium. Aus
Performanzgründen wird das komplette Laufzeitsystem auf die
Festplatte kopiert. Die gesamte Installation erfolgt von der CD-ROM.
3.2. Monolithischer Kernel
-
Der Kernel unterstützt keine Modularität. Alle notwendigen Treiber
befinden sich in dem Kernel-Image, das beim Systemstart geladen wird.
Späteres Hinzufügen von Treibern und Komponenten ist nicht möglich.
Damit wird die gefährliche Möglichkeit ein System auf Kernelebene zu
kompromittieren verhindert.
3.3 Das Whitelist-Verfahren
-
Durch das Whitelist-Verfahren wird ein vollkommener Schutz gegen
Viren und Fremdprogramme/Trojanische Pferde erreicht.
Das System wird in einen definierten Zustand gebracht. Zu diesem
Zeitpunkt befindet sich das System noch nicht online bzw. im
Produktionszustand. Von allen ausführbaren Dateien wird eine Liste
(die sogen. Whitelist) bestehend aus Dateiname und Checksumme
erstellt.
-
Die Checksumme wird durch eine stark kollisionsfreie Hashfunktion
erzeugt. Zur Anwendung kommt hier der Message Digest Algorithmus
(MD5) mit 128 Bit, jedoch sind beliebige Algorithmen anwendbar. Die
Verwendung eines stark kollisionsfreien Algorithmus verhindert, das
Dateien mit unterschiedlichem Bitmuster identische Checksummen haben.
Der MD5-Algorithmus gilt derzeit als sicher, wodurch eine Kollision
von Checksummen als unmöglich anzusehen ist. Desweiteren besteht eine
erhebliche Redundanz, da ein unterschiedliches Bitmuster mit einem
identischen Hashwert zusätzlich noch den Anforderungen des
ausführbaren Binärformates gerecht werden und im Falle eines
Spionageprogramms/Trojanischen Pferdes sinnvolle Maschinenbefehle
enthalten muß.
-
Die Whitelist wird beim aktivieren der Sicherheitsmechanismen
eingelesen und in einen vom Kernel geschützten Speicherbereich im RAM
des Computers gespeichert.
-
Zur Laufzeit wird jedes Programm vor Ausführung durch das System
anhand der Liste geprüft. Fehlende Einträge oder falsche Checksummen
verhindern eine Ausführung des Prozesses. Alle Programme, die nach
aktivieren des Whitelist-Schutzmechanismus über beliebige Wege auf
das System gelangen, können nicht ausgeführt werden. Viren und
Trojanischen Pferden ist es somit unmöglich Schaden anzurichten,
selbst wenn das System sie nicht als solche erkannt hat.
-
Das Whitelist-Verfahren folgt so dem Ansatz einer regelbasierten
Sicherheitsumgebung: Alles ist grundsätzlich verboten, nur über
explizit definierten Regeln (den Listeneinträgen) sind Ausnahmen
möglich.
3.4. Geschützte Prozesse
-
Prozesse, die im Kernel-Bereich geschützt sind, können zur Laufzeit
nicht beliebig durch Benutzer beeinflußt werden, nicht einmal durch
den Superuser. Dadurch wird verhindert, daß Angreifer Prüfprogramme
bei ihrer Arbeit behindern können.
3.5 Spezieller Partitions-Schreibschutz
-
Ausführbare Dateien werden auf einer Systempartition zusammengefaßt.
Dies gilt im Besonderen für indirekt ausführbare Dateien, den
dynamischen Biblitheken. Deren Checksummenüberprüfung wird aus
Performanzgründen ausgesetzt. Dies ist möglich ohne die Sicherheit
des Systems zu beeinträchtigen, da aus Biblitheken nicht direkt
Prozesse erzeugt werden können.
4. Implementation
-
Für die Realisierung dieses Verfahrens wurden Programme, Quellcodes
und Systemstrukturen erstellt:
- - Erweiterung des Linux Open Source Kernels um die Funktionalität
der Listenprüfung und Checksummenbildung sowie zum Starten von
durch den Kernel geschützte Prozessen.
Die Quellen werden entsprechend der General Public License (GPL)
offengelegt.
- - Ein Programm zur Erstellung der Listen und Checksummen
- - Eine Systemstruktur, die das Booten von CD-ROM ermöglich
- - Ein Laufzeitsystem, das sich ohne Neustart installiert
- - Hilfsprogramme zur Wartung des Systems
4.1 Erweiterungen des Linux Open Source Kerne
4.1.1. Steuerschnittstelle
-
Der Kernel enthält eine Erweiterung zur standardisierten
Steuerschnittstelle (/proc/sys). Über diese Schnittstelle ist es
möglich die Kernelerweiterungen zu konfigurieren. Angesteuert wird
die Schnittstelle über Unix-typische Dateimanipulationen.
-
Durch Schreiben eines Ganzzahlwertes in die Pseudo-Datei
"/proc/sys/bootlist" wird die Sicherheitsstufe gesteuert. Der Wert
"0" bedeutet, das die Sicherheitsfunktionen abgeschaltet werden. Der
Wert "1" bedeutet, das die Sicherheitsfunktionen aktiviert werden,
der Superuser kann jedoch durch das Schreiben einer "0" die
Sicherheit wieder deaktivieren. Der Wert "2" führt ebenfalls zur
Aktivierung der Sicherheitsfunktionen, jedoch ohne die Möglichkeit
für den Superuser, die Sicherheitsfunktion wieder abzustellen. In
diesen sichersten Modus kann nur ein Neustart des Systems eine
Änderung der Programm- und Checksummenliste wirksam machen.
4.1.2. Speicherung einer Whitelist im Kernel
-
Der Kernel wird mit einem zusätzlichen Parameter gestartet
(whitelist = <pfad/dateiname>). Dieser Parameter zeigt dem Kernel, von
wo er die Liste mit Programmen und Checksummen lesen soll.
-
Die Liste enthält in dem Format "<dateiname> <checksumme>" alle in
diesem System vorhandenen ausführbaren Dateien, denen das Starten
eines Prozesses erlaubt werden soll.
-
Bei Aktivierung der Sicherheitsfunktionen liest der Kernel diese
Datei, erkennt die Einträge und speichert sie im Kernelbereich des
RAM als doppelt verkettete Liste. Änderungen der Datei bei
aktivierter Sicherheit wirken sich nicht mehr auf den Kernel aus.
4.1.3. Zusätzlicher Kernel-Thread
-
In der Initialisierungsphase des Kernels werden sogen. Kernel-Threads
gestartet. Dies sind Prozesse die vom Kernel geschützt werden (wie
z. B. der INIT-Prozeß eines Unix). Der Prozeß kann selbst durch
Intervention des Superusers nicht beendet werden. Im HSS läuft ein
zusätzlicher Thread, der die Ausführung von Prüfprogrammen gestattet.
4.1.4. Prozeßüberprüfung
-
Der Kernel-Systemruf, der zum Starten von Prozessen zuständig ist
wurde so verändert das Prozesse die ausgeführt werden wollen vorher
überprüft werden. Die Funktion sucht die Binärdatei, die den
betreffenden Programmcode enthält und erzeugt eine Checksumme nach
dem MD5-Algorithmus. Der Name der Binärdatei wird in der von Kernel
verwalteten Whitelist (s. o.) gesucht. Ist der Name dort nicht
vorhanden, wird der Prozeß nicht ausgeführt. Ist der Name vorhanden,
wird die erstellte Checksumme mit der in der Liste gespeicherten
verglichen. Stimmen sie überein, wird der Prozeß ausgeführt.
Fehlgeschlagene Versuche werden dem Systemlogging übergeben. (s. u.)
4.1.5. Logging der Prozeßabläufe
-
Fehler die im Zusammenhang mit der Prozeßüberprüfung auftreten werden
in der Systemlog-Datei (/var/log/messages) sowie auf der
Standardfehlerausgabe von Unix-Systemen (stderr) ausgegeben.
-
Fehler die zu einer Eintragung in das System-Log führen sind:
- - Programme, die nicht in der Whitelist gespeichert sind
FEHLER: <DATEINAME>:<CHECKSUMME>
- - Programme, deren Checksumme nicht übereinstimmt
FEHLER: <DATEINAME>:<CHECKSUTMIME>
- - Symbolische Links, die nicht mit der Checksumme des verlinkten
Programms versehen sind
FEHLER: <DATEINAME>:<CHECKSUMME>
- - Dateiähnliche Konstrukte, deren Checksumme nicht bestimmt werden
kann (z. B. Sockets, Streams, Pipes, etc.)
FEHLER: <DATEINAME> ERROR_ON_CHECKSUM
4.1.6. Schreibschutz der Systempartition
-
Die Betriebsystembefehle, die für das Einbinden und Lösen von
Dateisystemen zuständig sind, wurden verändert. Bei aktivierter
Sicherheit ist es nicht möglich die Bindung der als /system
deklarierten Dateisystemeinbindung/Partition zu verändern.
4.2. Programm zur Erstellung der Listen und Checksummen
-
Das Programm (pnl) ist Bestandteil des Systems. Es dient dazu, die
gesamte Datenhierachie zu durchsuchen und alle ausführbaren Dateien
(Programme) zu identifizeren, eine Checksumme zu bilden und in eine
Liste zu schreiben. Die Liste dient dem Kernel später als Whitelist.
(s. o.: Aufruf und mögliche Parameter des Programms)
4.3. Bootbare CD-ROM
-
Die CD-ROM enthält ein Dateisystem gemäß ISO 9660 mit Rockridge
Extensions und einem Abbild einer startfähigen Diskette gemäß dem El
Torito Standard. Damit ist es jedem IBM-kompatiblen Computer mit
ATAPI-CDROM-Laufwerk möglich von dieser CD zu starten.
-
Der Betriebssystemkern wird grundsätzlich von der CD-ROM geladen.
Unmittelbar nach dem Laden nimmt der Kernel die Arbeit auf. Nach der
Hardware-Erkennung wird ein kleines Dateisystem-Abbild in den RAM
geladen. Dies ist das Kern-Dateisystem. Alle weiteren erkannten
Dateisysteme werden an dieses angehängt. Die benutzerdefinierten
Voreinstellungen werden von einer Diskette geladen und das
Laufzeitsystem entsprechend dieser Vorgaben installiert.
4.4. Laufzeitsystem
-
Das Kern-Dateisystem im RAM enthält ein Unix-typisches
Wurzelverzeichnis. Alle Medien werden laut benutzerdefinierter
Vorgabe hier eingehängt. Über dynamisch erzeugte Verweise
(symbolische Links) wird ein normales Unix-Dateisystem simuliert.
-
Durch die dynamischen Verweise ist es möglich alle Speichermedien, ob
schreibgeschützt oder nicht zur Laufzeit ohne Datenverlust aus dem
System zu entfernen und wieder einzufügen.
-
Selbst der gleichzeitige hardwarebedingte Ausfall aller
Speichermedien führt nicht zu einem Totalausfall des Systems (wohl
aber zu Datenverlust auf den Speichermedien und erheblichen
Einschränkungen im Betrieb). Sofern es die Hardware zuläßt,
Komponenten zur Laufzeit auszutauschen (HotSwap Devices) kann das
System mit Hilfe von Austauschkomponenten und Sicherheitskopien in
seinen Zustand vor dem Ausfall zurückversetzt werden, ohne das System
neu starten zu müssen.