Die Ansprüche in Sachen Sicherheit steigen – auch für die Pakete in den Archiven der Distributionen. Debians Reproducible-Builds-Projekt versucht, dem gerecht zu werden.

Darf man Software überhaupt noch vertrauen? Diese Frage stellt sich zunehmend, sobald man die Begehrlichkeiten der Staatsorgane sowie der ihnen willfährig zuarbeitenden Softwarefirmen einerseits betrachtet oder die Armee krimineller Hacker andererseits. Um ihre Ziele zu erreichen, versuchen die einen wie die anderen dem Nutzer manipulierte Software unterzuschieben.

Nun darf man in der Regel der verwendeten Distribution soweit vertrauen, dass die Pakete, die sie ausliefert, dem Quellcode entsprechen, aus dem sie gebaut wurden. Die Packages lassen sich auch nur schwer manipulieren, da die Inhalte der Archive die Signatur der GPG-Schlüssel der jeweiligen Paketbetreuer tragen. Allerdings gibt es auch Ausnahmen: So ließ sich Linux Mint kürzlich nicht nur ein manipuliertes Image unterschieben, sondern lieferte es auch noch an die Benutzer aus.

Debian stellt hier von Haus aus höhere Barrieren auf. Trotzdem fragten sich dort schon vor einigen Jahren einige Entwickler, was man tun könnte, um die Sicherheit weiter anzuheben. Die resultierende Idee: Der Anwender soll zu Hause überprüfen können, ob ein Paket Bit für Bit dem zugrundeliegenden Quellcode entspricht. Bereits um die Jahrtausendwende gab es auf der Debian-Entwicklerliste in Debian erste Anregungen zu reproduzierbaren Binärpaketen, die Idee wurde aber damals als nicht realisierbar abgetan.

Noch experimentell

Das noch in der experimentellen Phase befindliche Projekt, das diesen Grundgedanken wieder aufgenommen hat, nennt sich Reproducible Builds [1]. Nach rund zwei Jahren intensiver Arbeit könnte es 2017 mit Debian 9 “Stretch” an einem Punkt anlangen, an dem sich Debian zumindest teilweise reproduzierbar nachbauen lässt.

Als Endziel schwebt den Entwicklern vor, dass sich nicht nur alle Pakete reproduzierbar bauen lassen, sondern auch die dafür eigens erstellten Werkzeuge einen Weg in die Debian-Infrastruktur finden, um auch künftig Reproduzierbarkeit zu gewährleisten.

Das klare Versprechen des Reproducible-Builds-Projekts lautet: Jedermann kann zu jeder Zeit bitgenau identische Binärpakete eines gegebenen Quelltexts bauen (Abbildung 1). Geht es nach den Machern von Reproducible Builds, soll also künftig die Definition von freier Software die Reproduzierbarkeit zwingend mit einschließen (Abbildung 2).

Abbildung 1: Das Versprechen des Projekts: stets reproduzierbare, identische Binärpakete.

Abbildung 2: Die Definition von freier Software sollte bitgenaue Reproduzierbarkeit einschließen.

Breite Testbasis

Debians Reproducible-Builds-Team in Debian testet ständig in den Zweigen “Testing”, “Unstable” sowie “Experimental”. Aus den Ergebnissen erstellt es nicht nur eine viele Punkte umfassende Statistik [2], sondern veröffentlicht auch ein wöchentliches Nachrichtenblog [3]. Neben Debian treiben auch andere Distributionen die Reproduzierbarkeit von Binärpaketen voran, wie Arch Linux, Fedora, Subgraph OS und Tails. Ähnliche Initiativen finden sich auch in der BSD-Welt (NetBSD, FreeBSD) sowie bei Projekten wie Coreboot, OpenWRT, F-Droid und Guix.

Debian nutzt für das Erstellen der Reproducible-Builds 30 Host-Maschinen. Zusammen stehen für amd64, i386 und armhf rund 180 CPU-Kerne und über 300 GByte RAM zur Verfügung (Abbildung 3). Die Tests werden von Jenkins [4] gesteuert, einer Software zur kontinuierlichen Integration von Softwareprojekten. Dazu entstanden im Rahmen des Projekts insgesamt 41 Skripte mit rund 10?000 Zeilen Code.

Abbildung 3: Das Projekt testet unter verschiedenen Voraussetzungen, einschließlich anderer Distributionen.

Im Rahmen des Tests baut das System rund 10?000 Pakete je zweimal. Nach dem ersten Durchlauf ändert die Routine einige Gegebenheiten, wie Hardware, Architektur und Dateisystem, und vergleicht anschließend die Ergebnisse. Im Mai 2017 waren in Debian 21?365 von insgesamt 24?135 Quellpaketen reproduzierbar. Das entspricht im Durchschnitt der einzelnen Zweige 88,5 Prozent. “Testing” schneidet dabei mit über 90 Prozent besser ab als “Unstable” und “Experimental”.

Zu diesem Zeitpunkt ließen sich 1879 Pakete noch nicht reproduzierbar bauen, wobei bei zwei Dritteln der Grund bekannt war. Trotzdem sieht sich das Projekt noch weit vom Ziel entfernt: Holger Levsen, einer der Debian-Entwickler bei Reproducible Builds, sagte kürzlich in einem Vortrag [5], derzeit ließe sich Debian realistisch zu null Prozent reproduzieren – bislang handle es sich bei den Reproducible Builds noch um eine reine Machbarkeitsstudie (Abbildung 4).

Abbildung 4: Noch gilt das Projekt als experimentell, aber 90 Prozent der Debian-Pakete lassen sich bereits reproduzierbar bauen.

Identisches Build-System

Die wichtigste Grundvoraussetzung für reproduzierbare Builds liegt in der akribischen Aufzeichnung des Build-Systems. Es muss beim initialen Build genaue Informationen über die verwendeten Werkzeuge im Binärpaket selbst ablegen. Dazu schreibt es die entsprechenden Daten in eine neue Datei namens .buildinfo innerhalb der Paketstruktur. Bei darauffolgenden Builds liest das Perl-Skript Srebuild [6] diese Daten wieder aus und stellt sicher, dass ein identisches Build-System von Snapshots.org bezogen wird.

Ohne die Informationen über das Build-System lässt sich ein Paket nicht verlässlich nachbauen. Selbst eine leicht abgewandelte Bauanleitung (Compiler-Flag) führt auf Bitebene zu einem anderen Ergebnis. Hierbei kommt es zu dem Problem, dass durch die erweiterte Paketstruktur mit .buildinfo rund 100?000 zusätzliche Dateien pro Debian-Suite hinzukommen. Dadurch steigt die Menge an Code um bis zu 50 Prozent. Um die Spiegelserver zu schonen, sollen diese Zusatzinformationen daher nur auf den Debian-Servern direkt liegen.

Neue Werkzeuge

Technische Probleme bei der Reproduzierbarkeit entstehen zu 80 Prozent aufgrund neuer Zeitstempel sowie anderer Zeitzonen und Lokalisierungen.

Viele Build-Werkzeuge zeichnen Daten wie die Zeit und das Datum des Builds in nichtdeterministischer Form auf. Um das zu korrigieren, gibt es die Bibliothek strip-nondeterminism [7]. Sie entfernt im Vorfeld der Builds Informationen, die zu verfälschten Ergebnissen führen könnten (Abbildung 5).

Abbildung 5: Werkzeugkoffer: Die wichtigsten Tools im Rahmen des Reproducible-Builds-Projekts.

Um diese durch deterministische Werte zu ersetzen, wurde die Source_Date_Epoch [8] ersonnen. Dieser Zeitstempel definiert in einem String die Sekunden seit der letzten Modifikation des Quelltexts nach dem 1. Januar 1970, 0 Uhr UTC, also dem Start der Unix-Zeit.

Allerdings lassen sich nicht alle Probleme automatisiert lösen, sodass insgesamt noch viel Handarbeit ansteht. Zu den hier verwendeten Praktiken findet sich eine ausführliche Dokumentation [9]. Zum weiteren Handwerkszeug bei der Suche danach, warum sich ein Paket nicht reproduzierbar erstellen lässt, gehört an prominenter Stelle auch Diffoscope [10]. Mit diesem Werkzeug lassen sich Dateien oder Ordner in der Tiefe vergleichen (Abbildung 6). Dazu entpackt das Programm Archive und transformiert Binärpakete in von Menschen lesbare Formate.

Abbildung 6: Diffoscope erlaubt tiefgehende Vergleiche zur Fehlerfindung. Hier untersucht es zwei Firefox-Extensions.

Reproduzierbare Builds stellen einen wichtigen Schritt auf dem Weg zu jener Art von Sicherheit dar, die wir künftig brauchen, um die Integrität unseres digitalen Daseins zu verbessern. Als Allheilmittel taugen sie aber nicht: Geheimdienste und organisierte Kriminelle verfügen über Mittel, uns manipulierte Software unterzuschieben, gegen die es kaum eine Gegenwehr gibt.

Ein Beispiel dafür liefert die bereits 1974 erstmals beschriebene Trusting-Trust-Attacke [11]: Dabei manipuliert der Angreifer die Binärdatei eines Compilers dergestalt, dass sie sich erst einmal selbst neu kompiliert und der so manipulierte Compiler dann auf kaum erkennbare Weise veränderte Software ausspuckt, die beispielsweise Backdoors oder andere Gemeinheiten enthält.

Ein Bit genügt

Auch Ken Thompson [12], einer der legendären Väter von Unix, machte in einer amüsant zu lesenden Rede [13] anlässlich einer Preisverleihung klar, dass es keine absolut sichere Software gibt – es sei denn, man schreibt einen eigenen Compiler und baut alle Software selbst. Denn oft macht ein einziges Bit in einem 500 KByte großen Binärpaket den Unterschied zwischen einer sicheren und einer angreifbaren Software aus.

Dies belegten Tor-Entwickler in einem Vortrag [14] auf dem Chaos Computer Congress 2014 (31c3) anhand eines Fehlers im Netzwerkprotokoll SSH aus dem Jahr 2002 (CVE 2002-0083). Dort entschied ein einziges Bit darüber, ob sich jemand Root-Rechte auf der Maschine erschleichen konnte. Der Vortrag führte darüber hinaus einen Angriff vor, bei dem der Code eines Kernel-Moduls lediglich im Speicher geändert wurde. Auf dem Bildschirm erschien er dabei völlig intakt, das resultierende Binärpaket jedoch war kompromittiert.

Um solche und ähnliche Angriffe zu verhindern, begann die Idee der reproduzierbaren Builds zuerst bei Projekten wie Tor und Bitcoin Gestalt anzunehmen, da dort Sicherheit und Vertrauen eine zentrale Rolle spielen. Beide Projekte lassen sich seit 2012 gänzlich reproduzierbar bauen. Als Grundlage dafür dient Gitian [15], eine Distributionsmethode, die einen deterministischen Build-Prozess in einem Container oder einer virtuellen Maschine darstellt.

Mithilfe von Gitian Builder [16] bauen mehrere Personen unabhängig voneinander und der Umgebung das Paket. Stimmt alles, führt dies zu bitgenau identischen Binärpaketen. Für kleinere Projekte reicht Gitian aus, für eine komplette Distribution wie Debian mit zigtausenden Quellpaketen lässt es sich allerdings aufgrund des damit verbundenen Zeit- und Personalaufwands nicht gebrauchen.

Fazit

Bei den Distributionen nimmt Debian eine Vorreiterrolle in Sachen überprüfbare Pakete ein. Die dabei geschaffene Infrastruktur in Jenkins greifen mittlerweile andere Distributionen ebenso auf wie die Werkzeuge zum Lösen von Problemen und Überprüfen der Ergebnisse. So können etwa Fedora, OpenSuse oder Arch Linux die Ergebnisse von Debian verifizieren und umgekehrt.

Im letzten Jahr fand in Athen dazu ein distributionsübergreifendes Arbeitstreffen mit über 40 Teilnehmern statt, auch in diesem Jahr soll wieder eines stattfinden (Abbildung 7). Anfang August vermeldeten die Entwickler von Hardened GNU/Linux [17] – sie härten den Linux-Kernel mit PaX/Grsecurity – die Verfügbarkeit von Patches, um PaX/Grsecurity reproduzierbar zu bauen.

Abbildung 7: Auch 2016: europäisches Entwicklertreffen und GSoC-Beteiligung.

Damit entsteht Schritt für Schritt ein Netz des Vertrauens, das reproduzierbare Builds auch für solche Anwender vertrauenswürdig macht, die nicht selbst überprüfen möchten oder können, ob sich zwei Pakete bis aufs Bit gleichen. Die künftige Ausgestaltung des gesamten Prozesses und des Ergebnisses bedürfen weiterer Klärung – doch diese Probleme lassen sich lösen, sobald es erst einmal ein fast vollständig reproduzierbares Archiv gibt.