© Jane-Andoko, 123RF

Debians Reproducible-Builds-Projekt will technisch feststellen, ob ein Binärpaket auch tatsächlich aus dem zugehörigen Quellcode gebaut wurde. Das erhöht den Schutz vor Malware, aber auch den Aufwand.

Offene Software besitzt für die Nutzer einen entscheidenden Sicherheitsvorteil: Der Quellcode ist, anders als bei proprietärer Software, kein Betriebsgeheimnis, jeder kann ihn einsehen. Die erdrückende Mehrheit der Anwender installiert jedoch die vorgebauten Softwarepakete ihrer Linux-Distributionen. Sie verlässt sich darauf, dass die Systementwickler und Paketbetreuer dafür sorgen, dass die Binärpakete keinen von den Quellen abweichenden, bösartigen Code enthalten.

Bislang fehlte auch ein technischer Weg, um die Identität von Binär- und Quellpaket festzustellen. Das möchte Debians Reproducible-Builds-Projekt (RBP, [1]) längerfristig ändern (Abbildung 1).

Abbildung 1: Ist das Buildsystem kompromittiert, erhält das damit erzeugte Binärpaket im Reproducible-Build-System einen abweichenden Hashwert (roter Eintrag).

Angriffsszenarien

Als populäre Linux-Distribution verteilt Debian die eigene Software an eine große Anzahl von Nutzern weltweit. Die Abnehmer sind nicht nur Privatanwender, sondern auch Organisationen, Forschungseinrichtungen und Unternehmen. Das macht die Softwareverteilung zu einem interessanten Angriffsziel, um den ahnungslosen Anwendern bösartigen Code unterzuschieben.

Ein einleuchtendes Angriffsszenario besteht in der gezielten Manipulation von DEB-Binärpaketen. Wie der Open-SSH-Bug CVE-2002-0083 [2] zeigt, genügt es mitunter, ein einzelnes Bit zu verändern, um eine Hintertür in ein Programm einzubauen [3].

Für aufwändige Angriffe auf eine bestimmte Software ließe sich auch ein Kernel-Rootkit auf dem Rechner eines Paketbetreuers platzieren, das beim Kompilieren unbemerkt den Code verändert. Aktuell würde das Debian-Projekt dieses manipulierte Binärpaket nach bestem Wissen und Gewissen der System- und Paketbetreuer verteilen, ohne dass es zunächst auffiele. Die Auswirkungen der Manipulation zeigen sich, wenn überhaupt, erst später.

Binärpakete sichern

Die Idee, Binärpakete für Debian reproduzierbar zu machen, existiert bereits seit 2007 [4]. Anfangs stieß sie auf wenig Resonanz, bis dann entscheidende Impulse aus Projekten mit hohen Sicherheitsanforderungen kamen. So hat das Tor-Projekt den reproduzierbaren Paketbau vorangetrieben [5].

Seit den Snowden-Enthüllungen interessieren sich deutlich mehr Benutzer für den damit verbundenen Sicherheitsgewinn. Auch im Kreise der Bitcoin-Entwickler besteht ein besonderes Interesse daran, die Geldbörsen-Software, die das virtuelle Geld verwaltet, sicher an die Anwender zu verteilen.

Ungleich gebaut

Wer Manipulationen entdecken möchte, indem er abweichende Paketbau-Ergebnisse aufspürt, muss im ersten Schritt sicherstellen, dass der Buildprozess überhaupt identische Pakete erzeugt. Das ist in der Regel nicht der Fall. Vielmehr unterscheiden sich zwei aus demselben Quellcode gebaute Binärpakete häufig voneinander, wofür es verschiedene Gründe [6] gibt.

So ändern sich die erzeugten Pakete beispielsweise dann, wenn Entwickler sie auf verschiedenen Maschinen bauen. Oder der Buildprozess trägt abweichende Zeitstempel in die Header der mit Gzip generierte Archive oder in die mit »docbook-to-man« gemachten Manpages ein. In den Programmdokumentationen stecken Zeitstempel zum Beispiel auch in mit Doxygen [7] hergestellten HTML-Seiten oder in mit Latex [8] angefertigten PDF-Dokumenten.

Probleme bereiten zudem unterschiedliche Dateilisten, die entstehen, wenn die Posix-Funktion »readdir()« ihre Ausgabe nicht sortiert. Ein abweichender Baupfad führt zum Beispiel zu Änderungen an der Build-ID von Binärdateien. Die beim Bau verwendete Locale fällt bei unterschiedlichen Binärpaketen ebenso ins Gewicht wie der Hostname des Bausystems und viele andere Faktoren mehr.

Werkzeugkette

Zahlreiche Auslöser für diese unberechenbaren Abweichungen lassen sich in der für den Paketbau verwendeten Toolchain beseitigen. Ergänzend müssen die Entwickler jedoch auch die individuellen Quellpakete auf ihre Reproduzierbarkeit hin nachbearbeiten.

In bestimmten Fällen muss der Paketbetreuer sogar den Quellcode der Software patchen. Das ist beispielsweise der Fall, wenn ein Entwickler in C++-Code die Präprozessor-Makros »__TIME__« oder »__DATE__« verwendet [9], um beispielsweise beim Programmaufruf mit der Option »–version« zusätzlich das Baudatum mit auszugeben.

Manche Kleinigkeiten bekommen eine entscheidende Rolle, wenn es um Reproduzierbarkeit geht. Wer ihre Bedeutung nicht beachtet, kann das Paket an einem anderen Tag nur in einer angepassten virtuellen Umgebung identisch bauen. Auf solche virtuellen Bau-Umgebungen angewiesen zu sein, ist aber nicht Sinn der Sache, denn die Checksummen für die Binärpakete sollen sich unter allen möglichen Bedingungen identisch rekonstruieren lassen.

Die Reproducible-Builds-Arbeitsgruppe pflegt daher eine weiterentwickelte Toolchain für den deterministischen Paketbau [10]. Diese bietet etwa alternative Pakete von Doxygen und »docbook-to-man« sowie das Debhelper-Modul »dh_strip_nondeterminism« an, das unter anderem Zeitstempel aus einer Reihe von Objekten entfernt. Die Toolchain ist bisher rein experimentell, soll aber nach der Debian-8-Release nach und nach in den offiziellen Zweig einfließen.

Eine weitere Neuerung ist die überarbeitete ».buildinfo« -Kontrolldatei. Sie speichert nach einem Paketbau die benutzten Bauabhängigkeiten mit Versionsnummern, dem Baupfad sowie den Checksummen des Quell- und des erzeugten Binärpakets [11]. Mit diesen Informationen lassen sich beim erneuten Paketbau der Baupfad rekonstruieren und die verwendeten Abhängigkeiten aus dem Snapshot-Paketarchiv [12] nachvollziehen, falls sie veraltet sind.

Die experimentelle Toolchain funktioniert bereits jetzt in einer Bau-Umgebung im Chroot, zum Beispiel mit Pbuilder [13]. Paketbetreuer können sie also für erste Tests einsetzen. Daneben stellt das Debian-Projekt »debbindiff« [14] bereit, das zwei direkt hintereinander gebaute Pakete miteinander vergleichen kann. Es ist auch auf der Heft-DVD zu finden.

In die Infrastruktur

Das Projekt dockt inzwischen auch an Debians Infrastruktur an. Die Continuous-Integration-Plattform http://jenkins.debian.net überprüft das gesamte Paketarchiv laufend unter dem Aspekt, ob sich einzelne Quellpakete reproduzierbar erzeugen lassen [15]. Dafür baut es die Pakete direkt hintereinander mit absichtlich veränderten Parametern und vergleicht dann die Binärpakete, um Unterschiede zu entdecken.

Treten solche auf, erstellen die Entwickler Bugreports für das Paket, die zurzeit noch den Dringlichkeitsgrad »wishlist« tragen. Für diese Bugs steht zusätzlich eine Reihe vordefinierter Usertags bereit, die das aufgetauchte Problem kategorisieren, etwa »timestamps« , »fileordering« , »randomness« und so weiter. Nicht selten liefern die Projektentwickler zudem Patches an die Paketbetreuer.

Zukunftsmusik

Checksummen für die Binärpakete sind erst der Anfang, um Debian in Sachen Sicherheit weiter zu optimieren. Paketbetreuer würden künftig zum Beispiel nicht mehr ein auf ihrem Rechner vorgebautes Binärpaket hochladen, sondern nur noch das Quellpaket zusammen mit der ».buildinfo« -Datei senden.

Würde das Paket grundsätzlich auf einer Buildd-Maschine [16] gebaut, ließen sich die Checksummen direkt vergleichen, wobei das Projekt Pakete ablehnen könnte, falls Abweichungen auftreten [17]. Nicht reproduzierbar gebaute Pakete ließe man irgendwann womöglich gar nicht mehr in das offizielle Paketarchiv einfließen. Zugleich wären Checksummen-Abweichungen im Buildd-Netzwerk ein sicherer Hinweis auf ein manipuliertes Bausystem. Ausgeklügelte Szenarien wie Trusting-Trust-Angriffe [18], bei denen sich korrumpierte Bau-Umgebungen heimlich selbst fortpflanzen, ließen sich auf diese Weise effektiv vereiteln.

Um auf diesem Weg die Integrität des gesamten Debian-Archivs zu überwachen, müsste die Reproduzierbarkeit von Paketen allerdings für alle unterstützten Prozessorarchitekturen funktionieren. Das ist der nächste Schritt des Projekts, doch lauern hier womöglich noch unerkannte Tücken. Illusorisch ist aber wohl das Ziel, irgendwann das gesamte Paketarchiv reproduzierbar zu bauen.

Dem stehen noch einige besonders subtile Probleme im Weg. Das sind unter anderem Kompilierprozesse, die abhängig von der CPU-Auslastung und Speicherkonfiguration unterschiedliche Ergebnisse zeitigen. So wählt etwa GCC die Hash-Funktionen abhängig von der Größe des RAM-Speichers.

Dennoch möchte das Projekt seinem Ziel möglichst nahe kommen und bezieht deshalb auch Pakete ohne Programmcode ein, etwa Dokumentation. Würden die zugehörigen Bugs zudem den Dringlichkeitsgrad »important« oder »serious« erhalten, müsste ein Paketbetreuer begründen, warum er seine Pakete von diesem Ziel ausnimmt.

Dies besteht langfristig darin, die Software-Integrität bis hinunter auf die Hardware-Ebene mit Prüfsystemen abzusichern. Dafür fehlen aber noch Bausteine. So müsste das Projekt zum Beispiel nur noch von Entwicklern signierte Upstream-Tarballs akzeptieren.

Fazit

Bislang sind Reproducible Builds in Debian eine Erfolgsgeschichte: Am 13. Februar 2015 ließen sich zwischenzeitlich 83,5 Prozent aller Pakete reproduzierbar bauen (Abbildung 2, [19]). Die neue Bauweise wird wohl auch ein Veröffentlichungsziel für Debian 9 – und Debian ein Stück sicherer machen.

Abbildung 2: Im Februar 2015 erreichte die Zahl der Reproducible-Build-Pakete ein Zwischenhoch.