© view7, Photocase.com

Der Geheimagent dringt unerkannt in die Kommandozentrale des Gegners ein. Er läuft durch die Korridore und zeichnet Pläne der Komunikationsleitungen. Konspirativ untersucht er interne Abläufe und platziert schließlich an strategischer Stelle Wanzen sowie durch Fernzündung steuerbare Sprengsätze. Ein Ausschnitt des Drehbuchs des neusten Abenteuers von James Bond vielleicht? Es könnte aber auch als Bild für eine Gefahr bei der offenen Software-Entwicklung stehen.

Brächten Schurken die Zeit auf, sich in die Prozesse von Open-Source-Projekten einzuarbeiten, stünden die Chancen nicht schlecht, dass sie weitreichende Patches an strategischer, gleichwohl unauffälliger Stelle unterbringen könnten. So gelangten im November 2003 wenige, auf den ersten Blick unauffällige Zeilen in den Linux-Code von »kernel/exit.c«:

if ((options == (__WCLONE|__WALL)) &&
    (current->uid = 0))
        retval = -EINVAL;

Was auf den ersten Blick wie eine Plausibilitätsabfrage aussieht, entpuppt sich bei genauerem Hinsehen als ein Root-Exploit: Der Code scheint zu untersuchen, ob ein Anwender, der die beiden Flags »__WCLONE« und »__WALL« gesetzt hatte, wirklich Root-Rechte besitzt. Träte diese eigentlich sinnlose Kombination von Flags ein, wäre der erste Teil der Bedingung wahr. Nur in diesem seltenen Fall wertet der erzeugte Code die vermeintlich zweite Bedingung aus. Da hier jedoch eine Zuweisung mittels »=« statt eines Vergleichs mit »==« notiert ist, erhält der betroffene Prozess Root-Rechte [1]. In der internen Repräsentation von Linux hat der Superuser die UID 0.

Die Schwachstelle hatte ein Angreifer eingebracht, der sich Zugang zum damaligen Bitkeeper-Archiv verschafft hatte. Die Entwickler deckten sie letztlich nur auf, da der Angreifer einige Metadaten im Archiv falsch setzte, was dem Maintainer des SCM auffiel.

Niemand sollte die Gefahr unterschätzen, dass so etwas auch die eine oder andere Code-Review überwindet, wenn niemand explizit nach solchen Bedrohungen Ausschau hält.

Offenheit und Vertrauen

Der Kernelentwickler Richard B. Johnson sieht in dieser Erkenntnis keine einseitige Bedrohung des Entwicklungsmodells: “Letztlich ist jeder Open-Source-Kernel verwundbar. Das gilt aber auch für Closed-Source-Code.” Dort sind solche Schlupflöcher allerdings ungleich schwerer zu entdecken. Das CERT/CC fand beispielsweise 2001 heraus, dass im Code der Datenbank Interbase seit 1994 sieben Jahre lang unerkannt eine Backdoor eingebaut war, die Reviewer erst entdeckten, als der Hersteller Borland den Code unter einer offenen Lizenz veröffentlichte [2].

Doch ist das kein Freibrief für offene Projekte: Code-Reviews aus dem Blickwinkel der Sicherheit sind genauso wichtig wie vertrauensbildende Maßnahmen: Das verdeutlichte Unix-Veteran Ken Thompson bereits 1984: In einer frühen Unix-Version baute der Entwickler ein Patch in den C-Compiler ein, das prüfte, ob der gerade »/bin/login« übersetzte [3]. Dann fügte der Compiler zusätzlichen Code hinzu, der auch ein festgelegtes Masterpasswort zusätzlich zu den Einträgen in »/etc/passwd« erlaubte. Damit diese nur im Compiler-Binary manifestierte Backdoor auch längerfristig überlebt, ergänzte Thompson weiteren Code, der den Ergänzungscode auch beim Neu-Übersetzen des Compilers einfügte. Wer hat eigentlich zuletzt den GCC auf Assembler-Ebene gelesen?