Computer

Vor vielen, vielen Jahren (1984 um genau zu sein) veröffentlichte Ken Thompson eine Dankesrede für den Turing Award. Dieses Paper mit dem Titel "Reflections on Trusting Trust" sollte als eins der grundlegenden Paper in die Geschichte der Computersicherheit eingehen (genau genommen beschreibt das Paper lediglich die Arbeit von Paul Karger und Roger Schell, die die vorgestellte Attacke bereits 1974 formuliert hatten). Thompson beschreibt darin ein Dilemma, dem die Analyse eine sicheren Systems unterliegt: Mensch und Maschine verstehen unterschiedliche Sprachen. Der Quelltext eines Programms, welcher vom Menschen zu lesen ist, wird von der Maschine nicht verstanden. Diese versteht lediglich einen Binärcode, den wiederum der Mensch nicht (bzw. nahezu nicht) lesen kann. Die Übertragung von Quell- in Maschinencode geschieht durch Compiler.

Thompsons Idee basiert nun auf dem Problem des Bootstrappings: irgendwann muss der Prozess des kompilierens mal gestartet werden. Es muss also mal ein erster Compiler existieren, der diesen ersten Vorgang vornimmt. Dieser muss wiederum in Maschinencode vorliegen, denn sonst könnte ihn die Maschine nicht ausführen. An dieser Stelle setzt Thompson an und formuliert die Idee eine "bösen" Compilers, welcher bei der Übertragung vom Quell- in den Maschinencode die entstehende Software infiziert (mit einer Hintertür oder was auch immer). Diese ist so ausgelegt, daß sie, wenn der Compiler sich selbst übersetzen muss, dazu führt, daß die Routine zur Erzeugung der Hintertür wieder in den Compiler eingebaut wird (für genauere Ausführungen schaue man einfach in das Paper). An dieser Stelle hat man bei der Analyse eines sicheren Systems nun ein Problem: entweder man vertraut diesem ersten Compiler und kann dann (theoretisch) allen weiteren Quellcode analysieren um so sicherzustellen, daß das System keine Hintertüren hat oder man kann ihn nicht verwenden (der paranoide Ansatz lautet dann hier: man kann keinen verwenden, denn es könnte ja jeder eine Lücke haben). Sicherheit, die auf Analyse basieren will, hat mit Vertrauen so ihre Schwierigkeiten. Das Problem des "bösen" Compilers blieb lange ungelöst. Bis jetzt...

Im Dezember 2005 veröffentlichte David A. Wheeler "Countering Trusting Trust through Diverse Double-Compiling", ein Paper, welches die Lösung des beschriebenen Problems darstellt. Schaut man sich an, wie trivial diese Lösung ist, so kann man nur den Kopf schütteln, das man nicht früher drauf gekommen ist. Die Idee ist folgende:

Nehmen wir an, wir haben zwei Compiler (als Binaries) A und B und den Quellcode Sa von A. Wir kompilieren nun Sa sowohl mit A, als auch mit B und erhalten Ca und Cb. Diese beiden Binaries dürften unterschiedlich sein, da sie mit verschiedenen Compilern erzeugt wurden. Durch unterschiedliche Optimierungsstrategien etc. können sie sich auf Byteebene unterscheiden. Sie sind allerdings funktional äquivalent, will heißen: sie tun exakt dasselbe (zumindest sollten sie das). Nun kompilieren wir Sa nochmal mit Ca und mit Cb. Hieraus resultieren dann die Binaries Ea und Eb. Da Ca und Cb funktional absolut identisch sein sollten, sollten auch Ea und Eb bitgenau gleich sein. Sind sie es nicht, so ist entweder A oder B nicht vertrauenswürdig und muss verworfen werden. Ersetzt man B nun durch einen vertrauenswürdigen Compiler T, so kann man prüfen, ob A vertrauenswürdig ist. Der vertrauenswürdige Compiler wird in diesem Modell lediglich verwendet, um Sa zu übersetzen. Es ist vollkommen egal, wie langsam der ist und ob der irgendwelche Optimierungen etc. beherrscht. Er kann also so einfach, wie möglich gebaut werden, im Extremfall direkt in Maschinensprache. Man hat auf diese Art und Weise das Problem aus dem Ursprungspaper gelöst: es besteht wieder ein direkter Zusammenhang zwischen dem vom Quellcode beschriebenen Verhalten und dem ausgeführten Code auf dem Prozessor. Für einen Menschen ist die Analyse des Quellcodes unendlich viel einfacher, als die des Maschinencodes. Über 30 Jahre nach der Formulierung des ursprünglichen Problems gibt es nun eine Lösung und diese ist auch noch so einfach und leicht nachvollziehbar. Meinen Respekt, Mr. Wheeler...

Quellen:

• http://www.acm.org/classics/sep95/
• http://www.acsa-admin.org/2005/papers/47.pdf
• http://www.schneier.com/blog/archives/2006/01/countering_trus.html

Da ich gerade meinen Webserver umziehe, bin ich auf ein eher unnettes Problem gestoßen: Wenn man einen SSL-gesicherten Virtual Host von einem Server auf den anderen umzieht, dann sollte man daran denken, in der <VirtualHost IP:443>-Deklaration auch die IP zu ändern. Tut man das nicht, so fängt der Apache nämlich kommentarlos an, auf Port 443 Plaintext zu sprechen, da er kein Interface mit der alten IP findet, auf das er diesen Virtual Host packen kann. Es greift also die eventuell vorhandene Definition ohne Port. Fehlermeldungen oder ähnliches sind leider auch nicht vorhanden, so daß die Suche einigermaßen kompliziert wird...

Aus gewissen Gründen haben wir den Flatrate-Provider gewechselt. Congster erschien ganz günstig, direkt im Backbone der Telekom (Kunststück: als Tochter) etc. Ergo Tiscali gekündigt und neue Flat beantragt. Alles wunderbar, geht nach ein paar Minuten. Das heißt: es geht theoretisch. Praktisch wurden wir nämlich vom Login-Server immer abgewiesen. Tja, nach einigem Rumprobieren haben wir es erstmal gelassen. Heute nochmal probiert, selbes Problem. Also irgendwann mal die Hotline angerufen und gefragt... Das Passwort darf nur Kleinbuchstaben und Zahlen haben. WAS? Habt ihr eigentlich total einen an der Waffel? Soll ich mein Passwort vielleicht direkt an die Hausmauer schreiben? *narf* Das Passwort muss zwischen 5 und 12 Zeichen lang sein. Ok, die Hotline war so nett, uns das durch mehrmalige Logins gesperrte Passwort zurückzusetzen. Das generierte Passwort war 4 Zeichen lang. Doll, ihr könnt echt was! Zuguterletzt haben wir uns also ein zufälliges Passwort nach den Kriterien generiert und schon geht's. Na wunderbar. Mal schauen, wie der Rest der Technik so wird. Verbindungsaufbau ist jedenfalls wesentlich schneller als bei Tiscali. Der Rest... naja, werden wir merken.

Grad im ICQ:

******** 16:45:51: puuh, jetzt hab ich mich aber selber verarscht
NAMENLOS 16:46:07: Wieso?
******** 16:46:28: typedef enum{true=0, false=1} tBool;
******** 16:47:04: wie doof
NAMENLOS 16:48:07: ROTFL. Schön.
NAMENLOS 16:49:49: Ich darf dich bloggen?
******** 16:50:08: jaja, tu nur
NAMENLOS 16:50:24: :) Ich mach's auch anonym
******** 16:51:42: *g* danke

Hihi...

P.S: Weil ich weiß, daß er/sie/es es liest: es ist im allgemeinen keine Gute Idee (TM) schlüsselwörter von C++ in C zu verwenden...