Im Zeitalter von ständigen Supply-Chain-Angriffen installiert RPM Software-Pakete, obwohl deren Schlüssel offensichtlich ungültig sind.
(Bild: zffoto/Shutterstock.com)
Security Von
- Jürgen Schmidt
Das Linux-Paketverwaltungs-Tool RPM prüft zwar die digitale Signatur der zu installierenden Pakete, nicht aber die PGP-Schlüssel mit denen diese erstellt wurde. Jedenfalls prüft sie nicht, ob dieser Schlüssel bereits widerrufen und somit ungültig ist. Das stellte der Entwickler Dmitry Antipov fest und meldete es mit einem Bug-Report dem Entwicklerteam. Den ergänzte er sogar gleich durch einen Patch, der die benötigte Funktionalität nachrüsten sollte.
Was ihn störte, war die Tatsache, dass RPM Software-Pakete auch dann installierte, wenn der signierende Schlüssel offensichtlich ungültig ist. Also wollte er das ändern. Doch die prompte Antwort eines Entwicklers lautete, der fehlende Check sei eigentlich kein Bug, sondern "einfach überhaupt nicht umgesetzt". Ähnlich wie das Überprüfen eines Ablaufdatums übrigens. Bereits abgelaufene Schlüssel funktionieren nämlich auch klaglos. Und das eigentlich schon seit immer …
Schlaue Problemvermeidung
Damit ging es im März los. Heute fasste ein weiterer Entwickler den Sachverhalt so zusammen: "Das ist keine Verwundbarkeit. Das ist ein grundlegendes Missverständnis, wie RPM arbeitet". Die RPM-Entwickler wollen zwar die Vertrauenswürdigkeit eines Pakets prüfen, sich dabei aber nicht auf die Komplexität von Trust Management einlassen. Wenn ein Schlüssel nicht mehr vertrauenswürdig ist, muss ihn jemand aus der Datenbank der vertrauenswürdigen Schlüssel entfernen. Das sei aber nicht die Aufgabe von RPM. Für RPM ist jeder dort hinterlegte Schlüssel okay.
Dieser Ansatz ist auch schlau. Denn mit einem einfachen Patch, der die fehlenden Tests nachrüstet, wäre es keineswegs getan. Beim Ablaufdatum wäre das noch relativ einfach. Denn die Information, wie lange der Schlüssel gültig sein soll, ist im OpenPGP-Schlüssel enthalten und sogar digital signiert. Doch was macht man mit einem Paket, dessen signierender Schlüssel zwar damals gültig war, zum Zeitpunkt der versuchten Installation aber bereits abgelaufen ist?
Noch viel schlimmer ist es mit dem Widerruf. Es gibt bei OpenPGP zwar einen Mechanismus, mit dem der Besitzer einen Schlüssel sperren kann. Doch wie das dabei erstellte Widerrufszertifikat zum Nutzer kommen soll, ist nicht festgelegt. Es gibt auch keine zuständige Instanz, bei der RPM mal nachfragen könnte, ob denn der Schlüssel XYZ zwischenzeitlich gesperrt wurde oder noch gültig ist.
Erschwerend hinzu kommt die Frage, was man mit den Paketen macht, die vor einem Widerruf signiert wurden. Das hängt dann etwa davon ab, ob der Widerruf im Rahmen eines routinemäßigen Schlüsselwechsels erfolgte oder der Key kompromittiert war. Die RPM-Entwickler wären nicht die Ersten, die feststellen, dass das richtige Sperren von Schlüsseln eine fast unlösbare Aufgabe ist.
Moderne Alternativen
Das sind Probleme, deren Komplexität eine schnelle Lösung unmöglich macht. Es ist also durchaus im Sinne der weiteren Funktionsfähigkeit des wichtigen Linux-Installations-Werkzeugs RPM, dass sich dessen Entwickler nicht mit diesen Problemen belasten. Ob es aber zeitgemäß ist, dass ein ganz offensichtlich ungültiger Schlüssel als Vertrauensanker für Software-Installation dienen kann, ist eine andere Frage.
Die sollten sich die Distributionen, die RPM einsetzen, möglichst bald stellen. Denn das Einschleusen von bösartigem Code über die Lieferkette entwickelt sich gerade zu einem massiven Problem. Und da kann man sich dann auch gleich fragen, ob die eierlegende Krypto-Wollmichsau PGP wirklich das richtige Tool dafür ist, so etwas zu verhindern oder zumindest möglichst schwer zu machen. Oder ob nicht ein schlankes Tool wie das aus der OpenBSD-Welt stammende signify dafür besser geeignet wäre. Dessen Entwickler hat sich übrigens dafür entschieden, den Widerruf von Schlüsseln erst gar nicht vorzusehen und setzt stattdessen auf zügige und weitgehend automatisierte Schlüsselwechsel.
(ju)
Quelle: www.heise.de