© Andriy Popov, 123RF

Seriöse Distributionen versuchen ihre Repositories kryptographisch gegen Manipulationen und Übertragungsfehler zu schützen. Konzeptionell zwar ähnlich, gehen Arch Linux, Debian, Fedora, Open Suse und Ubuntu dabei unterschiedlich aufwändige Wege.

Viele Distributionen entwickeln, testen, bauen und verteilen ihre Software auf einem gewachsenen Zoo von Servern, Mirrors und Arbeitsrechnern, die zentral zu managen und abzusichern kaum möglich scheint. Personell sind sie zudem auf die Mitarbeit einer schwer überschaubaren Anzahl internationaler Helfer angewiesen. Die technische und menschliche Diversität entfaltet eine sehr große Angriffsfläche für externe und interne Angreifer, die danach trachten, gängige Pakete der Distribution mit Malware zu spicken. Beim nächsten Update ziehen sich Hunderttausende Linux-Rechner vergiftete Software und installieren sie unter Rootrechten. Der Schaden könnte größer kaum sein.

Und die Gefahr ist weniger abstrakt, als mancher meint. Die Vergangenheit hat gezeigt, dass immer wieder Projekte nach Hackerangriffen einen oder mehrere Server vom Netz nehmen mussten. Entsprechend groß ist die Motivation zumindest aller großen Distributionen, sich vor untergeschobenen Paketen zu schützen. Im Kern geht es um zwei Maßnahmen – eine simple und eine kryptographische.

Höhere Mathematik

Zum einen berechnen die Projekte für jedes Paket eine Prüfsumme. Mit ihr können Anwender feststellen, ob das Paket fehlerfrei durch das Internet geflutscht ist. Die Hashverfahren MD5, SHA1 und SHA256 sind dafür gängig.

Weil Prüfsummen keinen Schutz gegen beabsichtigte Manipulationen bieten, signieren Arch Linux, Debian & Co. zudem ihre Pakete und Repositories. Das tun sie naheliegenderweise mit Public-Key-Kryptographie. Die Basis bildet ein einmal angelegtes Schlüsselpaar. Mit dem Private Key, der unter Verschluss bleibt, signiert das Projektteam die neuen Pakete oder das Repository. Mit dem Public Key, der auf den Distributions-Webseiten und Installationsmedien für jedermann zugänglich ist, prüfen Anwender, ob die Signatur vom Besitzer des Private Key und somit tatsächlich dem Projekt stammt.

Geheimniskrämerei

Um die Sicherheit zu erhöhen, setzen einige Distributionen gleich auf eine Kette aus Signaturen und Prüfsummen. Wie sie genau dabei vorgehen und was sie technisch umsetzen, geben die Projekte auf ihren Internetseiten allerdings nur in homöopathischen Dosen preis. Die wenigen Informationen verteilen sich obendrein noch auf gleich mehrere Unterseiten, andere sind veraltet.

Fast nichts erfährt man über die internen organisatorischen Abläufe. So bleibt es Interessenten unklar, welches Team-Mitglied wann welche Pakete mit welchem Schlüssel signiert – oder ob dies sogar automatisch geschieht. Für die Distributionen Arch Linux, Debian, Fedora, Open Suse und Ubuntu lassen sich die Abläufe immerhin einigermaßen rekonstruieren.

Arch Linux

Die Macher der Slackware-ähnlichen Rolling-Release-Distribution mit Debian-ähnlicher Paketverwaltung setzen auf Gnu-PG und das Web-of-Trust-Konzept [1]. Ein Entwickler stellt zunächst für seine Software ein passendes Paket zusammen und signiert es via Gnu-PG selbst. Dann lädt er es ins Arch User Repository (AUR) und behält zunächst die Verantwortung für sein Paket. Sofern es sich in diesem Repository bewährt, wandert es weiter ins »community«-Repository.

Das AUR und das Community-Respository verwalten ausgewählte Arch-Linux-Nutzer, die so genannten Trusted Users [2]. Jeder von ihnen darf die von ihm betreuten Pakete mit einem eigenen Gnu-PG-Schlüssel signieren. Sollte das Arch-Linux-Team eines der Pakete als besonders wichtig einstufen, wandert es weiter in eines der anderen offiziellen Repositories, etwa »core« oder »extras«. Die Pakete in diesen Repositories verwalten wiederum die Core-Arch-Linux-Entwickler.

Das Projekt besitzt fünf offizielle Gnu-PG-Schlüssel, die Master Signing Keys (Abbildung 1). Jeder Key gehört genau einem von fünf Arch-Linux-Entwicklern [3]. Mindestens drei dieser Schlüssel signieren immer jeweils einen Schlüssel der Paketentwickler und der Trusted User, die ihrerseits mit ihren so beglaubigten Schlüsseln die Pakete signieren. Die Signatur zu einem Paket wandert in eine separate Datei mit der Endung ».sig«, die das jeweilige Repository zusammen mit dem Paket anbietet.

Aufgrund des auf diese Weise entstehenden Web of Trust kann der Paketmanager Pacman die Signaturen prüfen: Sobald ein Paket mit einem Schlüssel signiert ist, der mit mindestens einem gültigen Master Signing Key unterschrieben ist, muss es folglich aus dem Arch-Linux-Projekt stammen.

Zu jedem der Master Signing Keys gibt es ein Widerrufszertifikat, das in den treuen Händen eines anderen unabhängigen Arch-Linux-Entwicklers liegt. Diese Maßnahme verhindert, dass einer der Master-Key-Inhaber die alleinige Macht über den Zertifizierungsprozess erlangt. Welche Pakete in einem Repository stecken, verrät eine kleine Datenbank. Sie enthält auch zu jedem Paket die zugehörigen MD5- und SHA256-Prüfsummen.

Abbildung 1: Bei Arch Linux dienen die fünf Master Signing Keys als Ausgangspunkt für eine Kette aus Signaturen.

Debian

Welche Pakete ein Debian-Repository anbietet, verraten auf mehrere Unterverzeichnisse verteilte Dateien mit dem Namen »Packages«. Auch liefern die Dateien zu jedem Paket ermittelte MD5-, SHA1-, und SHA256-Prüfsummen. Die Speicherorte der »Packages«-Dateien listet wiederum eine Datei namens »Release« auf. Zu jedem »Packages«-File verrät sie die zugehörige Prüfsumme.

»Release« signiert das Debian-Team mit einem automatisch erzeugten Schlüssel, den die Dokumentation wahlweise als Automatic Signing Key oder FTP-Master-Key bezeichnet [4]. Derzeit gibt es pro Debian-Release nur genau einen FTP-Master-Key (Abbildung 2), früher fertigte das Projekt-Team jedes Jahr einen neuen FTP-Master-Key an.

Die »Release«-Dateien jeder stabilen Debian-Version signiert das Team mit dem automatischen Signing Key, der zum Release-Zeitpunkt in Gebrauch ist. Stable-Releases signiert das Debian-Team zusätzlich mit einem für die entsprechende Release generierten Stable Key. In jedem Fall landen die Signaturen in der separaten Datei »Release.gpg«.

Die »Release«-Dateien für die speziellen Releases »proposed-updates«, »testing«, »testing-proposed-updates«, »unstable«, »experimental« sowie für das Security Archive signiert Debian nur mit dem FTP-Master-Key. Die Keys lassen sich für alle Debian-Releases unter [4] einsehen und herunterladen (Abbildung 2).

Abbildung 2: Das Debian-Projekt bietet seine Schlüssel auf dieser Seite zum Download an. Darunter fallen auch die für ältere Versionen und solche, die nicht mehr in Gebrauch sind.

Ach, echt!

Das Signieren und die Key-Verwaltung erledigt das FTP-Master-Team, das auch für den Betrieb des Debian-Archivs verantwortlich zeichnet [5]. Durch die verketteten Signaturen und Prüfsummen lässt sich die Echtheit eines Pakets eindeutig ermitteln: Stimmt die Signatur der »Release«-Datei, darf die Paketverwaltung dem Inhalt vertrauen. Die Release-Datei enthält wiederum die Prüfsummen der »Packages«-Dateien mit den eigenen Paketen. Stimmen die Prüfsummen, sind auch die Inhalte der »Packages«-Dateien unverändert.

Mit den in ihnen enthaltenen Prüfsummen kann der Benutzer die Unversehrtheit der einzelnen Pakete nachvollziehen. Zudem bringt jedes Paket eine Textdatei mit, die MD5-Prüfsummen aller mitgelieferten Dateien bereithält.

Bevor ein Paket in einem offiziellen Debian-Repository landet, muss der Entwickler einen anerkannten Paketbetreuer finden. Als so genannter Sponsor prüft dieser das Paket und lädt es dann nach der Begutachtung in ein Repository hoch. Das Debian-Projekt unterscheidet zwei Arten Paketbetreuer: Ein Debian Maintainer (DM) darf nur seine eigenen Pakete hochladen, während der Debian Developer (DD) als Debian-Mitglied jedes Paket einstellen kann.

Fedora

Sobald die Arbeit an einer neuen Fedora-Version beginnt, erzeugen die Entwickler einen neuen Gnu-PG-Schlüssel [6]. Mit ihm signieren sie jedes einzelne vom Projekt veröffentlichte RPM-Paket. Der Schlüssel kommt sowohl bei den öffentlichen Testversionen als auch bei der finalen Fassung zum Einsatz.

Jede Architektur besitzt zudem ihren eigenen Schlüssel. In jedem Fall sind die Signaturen in den Metadaten des jeweiligen RPM-Pakets enthalten. Lediglich einige Bleeding-Edge-Pakete in der Distributionsvariante Rawhide besitzen keine Signatur.

Es ist die Aufgabe der Paketmanager »dnf« und »rpm« sowie der entsprechenden GUI-Tools, die Signaturen zu prüfen [7]. Die dazu notwendigen öffentlichen Schlüssel lagern nach der Installation von Fedora im Verzeichnis »/etc/pki/rpm-gpg« (Abbildung 3). Alternativ finden Anwender die öffentlichen Schlüssel unter [8].

Die Schlüssel verwaltet und erzeugt das Fedora-Team mit dem Tool Sigul [6]. Alle handverlesenen Projektmitglieder, die Pakete zu signieren haben, die so genannten Release Engineers [9], haben auch Zugriff auf den Schlüssel.

Abbildung 3: Fehlt einem Fedora-System ein öffentlicher Schlüssel zum Verifizieren, fordert der Paketmanager – hier »dnf« – den Systemverwalter zum Import auf.

Open Suse

Jedes einzelne Suse-RPM-Paket ist mit einer Gnu-PG-Signatur unterzeichnet, die in den Metadaten des RPM-Pakets zu finden ist. Typisch für Suse-Distributionen ist, dass sie automatisch im Open Build Service [10] entstehen, der von Open Suse betriebenen öffentlichen Entwicklungsplattform. Die GPL-Software des System signiert automatisch alle Pakete und Medien, die es durchlaufen.

Ludwig Nussel, Release-Manager von Open Suse Leap, berichtet auf Nachfrage des Linux-Magazins, dass am Build Service ein eigener Signierhost über eine separate Leitung angeschlossen sei, auf dem der private Teil des offiziellen Schlüsselpaars liegt. Nur Mitarbeiter mit besonderer Sicherheitsfreigabe haben Zutritt zu dem Serverraum, nicht mal Release-Chef Nussel selbst dürfe hinein. Er versichert, dass auf diesem Rechner nichts läuft außer dem Signierservice, auch kein SSH-Server. Logins seien nur über eine serielle Konsole möglich.

Suse-Key als Backup

In jeder Open-Suse-Installation sind die öffentlichen Teile zweier Schlüssel in der Datei »content.key« vorinstalliert: Der Open Suse Project Signing Key »opensuse@opensuse.org« und der Suse Package Signing Key »build@suse.de«. Suse hat bislang keinen Grund gesehen, die Schlüssel zu erneuern. Sie besitzen aber ein Verfallsdatum, das die dazu Berechtigten regelmäßig verlängern.

Sollte der private Open-Suse-Schüssel aber mal verloren gehen, würde das Projekt den Suse-Schlüssel benutzen, um ein Update zu verteilen, das den kompromittierten Schlüssel löscht und einen neuen Open Suse Project Key ausrollt. Der private Suse-Schlüssel lagert in einer separaten Infrastruktur analog zu der oben beschrieben.

Das Projekt flicht Vertrauensketten …

Auf den Schlüsseln fußt in den Repositories und auf den Installationsmedien eine mehrstufige Absicherung, die der von Debian ähnelt [11]: Im Zentrum steht die Datei »content«, die das Verzeichnis mit den Paketen verrät. Der Open Build Service signiert die Datei vor der Auslieferung, wobei die Signatur in der Datei »content.asc« landet. »content« verweist auf weitere Dateien, die wiederum die Dateinamen aller Pakete enthalten. Für jede der Dateien liefert »content« die passende SHA256-Prüfsumme.

Außerdem verweist »content« auf Dateien mit anderen öffentlichen Schlüsseln, die Yast klaglos importiert, da »content« bereits eine vertrauenswürdige Signatur besitzt. Die Schlüssel sollen dabei helfen, die Signaturen in den RPM-Paketen zu prüfen. Als Nächstes greift sich Yast die passende, von der Datei »content« genannte »packages.gz«-Datei. Sie enthält alle im Repository enthaltenen Pakete mit ihren jeweiligen SHA1-Prüfsummen.

Auf diese Weise bildet sich wie bei Debian eine Vertrauenskette (Chain Of Trust). Pakete, die beim Installieren ihre Herkunft nicht beweisen können, weist Yast ab (Abbildung 4), »rpm« bemerkt den Betrugsversuch zwar auch, reagiert aber nachsichtig (Abbildung 5).

Abbildung 4: Schlägt in Open Suse Leap 42.2 die Signaturprüfung eines Pakets fehl, unterbricht Yast die Installation. »Ignorieren« spielt das Paket dennoch ein.

Abbildung 5: Das Tool »rpm« unter Open Suse Leap bemerkt zwar den zweifelhaften Leumund eines Pakets, installieren es aber trotzdem.

… auch jenseits von RPM

Nach dem gleichen Prinzip wie bei RPM sichert das Open-Suse-Projekt seine Repositories im »repomd«- und Yum-Format. Dort ist die zentrale »repomd.xml«-Datei mit einer Signatur aus der separaten Datei »repomd.xml.asc« unterlegt. Der zur Prüfung notwendige öffentliche Schlüssel ist entweder mit dem des Installationsmediums identisch (etwa bei einem Update-Repository) oder er liegt in der Datei »repomd.xml.asc«. Ist der Schlüssel dem System unbekannt, muss ihm der Anwender wieder explizit das Vertrauen aussprechen.

Die Datei »repomd.xml« enthält eine Liste mit weiteren Dateien nebst ihren zugehörigen SHA256-Prüfsummen. Diese zusätzlichen Dateien enthalten dann unter anderem eine Aufstellung aller im Repository enthaltenen Pakete. Auch hier bildet sich wieder eine Chain of Trust: Stimmt die Signatur der Datei »repomd.xml«, sind die in ihr enthaltenen Prüfsummen vertauenswürdig. Mit diesen Prüfsummen kann man dann wieder herausfinden, ob die zugehörigen Dateien im Repository verfälscht worden sind.

Ubuntu

Ubuntu sichert seine Pakete nach dem gleichen Prinzip wie das grundlegende Debian. Die »Release«-Datei signiert aber Canonical. Da Ubuntu die meisten Pakete aus den Debian-Repositories übernimmt, empfiehlt Canonical sogar Ubuntu-Entwicklern, ihre Programme zunächst bei Debian einzureichen [12].

Eine kleine Ausnahme bilden die Personal Package Archives (PPAs). Jeder Entwickler darf auf der Plattform Launchpad schnell sein eigenes Repository einrichten und darüber seine Software für Ubuntu-Nutzer ausliefern. Launchpad erzeugt für jedes PPA einen eigenen kryptographischen Schlüssel, mit dem die Plattform automatisch jedes vom PPA angebotene Paket signiert [13]. Im Hintergrund arbeitet dabei das gleiche System wie bei Debian: Ein PPA besteht aus einem kleinen Repositoriy mit einer eigenen »Release«-Datei, die Launchpad mit dem PPA-Schlüssel signiert.

Die neuen Snaps dagegen (siehe ersten Schwerpunkt-Artikel) müssen Entwickler ähnlich wie Smartphone-Apps in Canonicals Store einstellen. Dort durchläuft die Software einen automatischen und von Fall zu Fall auch einen manuellen Review-Prozess.

Prinzip Hoffnung

Es wäre ein Einfallstor allererster Güte, gelänge es Angreifern, einer Distribution ein Backdoor-vergiftetes Paket unterzuschieben. Entsprechend hoch sollte die Motivation jedes Systemverantwortlichen sein, dies zu verhindern. Alle hier betrachteten Distributionen beschreiben in ihren Wikis ausführlich, wie Anwender die Herkunft eines Pakets überprüfen sollen. Erstaunlich wenige Informationen halten sie jedoch bereit über die eigenen organisatorischen und technischen Abläufe im Hintergrund. Diese Zugeknüpftheit passt schlecht zur Transparenz von Open Source und könnte der verzweifelten Hoffnung auf Security through Obscurity entspringen.

Debian, Ubuntu und Open Suse hantieren (für Open Suse vereinfacht gesagt) mit nur einen Gnu-PG-Schlüssel, der eine zentrale Informationsdatei im Repository signiert. Von dieser Datei ausgehend prüft dann der Paketmanager die einzelnen Pakete. Das macht den zentralen Schlüssel dort zum lukrativen Angriffspunkt.

Nur Arch Linux versucht das Problem über gleich fünf Master-Keys zu entschärfen. Unklar bleibt jedoch in vielen Fällen, wo und wie das Projekt die zum Signieren verwendeten privaten Schlüssel aufbewahrt.