Da ist jetzt schon eine ziemliche Bombe geplatzt. Das neben dem DEB/APT wichtigste Paketmanagerformat RPM unterstützt die OpenPGP-Signierung nur lückenhaft. Es sieht keine Überprüfung abgelaufener oder ungültiger Schlüssel vor.
Was ist das Problem?
Gestern berichtete bereits Golem über das Problem. Die Paketverwaltung RPM hat ein Problem mit der Signatur von Paketen. Die Software unterstützt schlicht keine abgelaufenen oder zurückgezogenen Schlüssel. Mit solchen Schlüsseln signierte Pakete werden einfach weiter akzeptiert.
Aufgebracht hatte das Problem ein Linux-Entwickler von Cloudlinux, die mit Alma nun einen Klon von RHEL erschaffen haben und sich anschicken, die Nachfolge von CentOS anzutreten. Es handelt sich hierbei streng genommen um keinen Fehler, da die Funktion schlicht und ergreifend nicht implementiert ist.
Inwieweit diese Implementierung jetzt nachgeholt wird, bleibt abzuwarten. Vor allem ist fraglich, wie schnell das wirklich flächendeckend ausgerollt wird, da Upstream-Änderungen bei RPM oft erst mit viel Verzögerung in den Distributionen landen.
Warum ist das ein Problem?
Angreifer können dieses Problem ausnutzen, um mit abgelaufenen oder zurückgezogenen Schlüsseln schädliche Pakete zu signieren und zur Installation verwenden. RPM hat weder einen guten Schlüsselspeicher, noch gibt es die Möglichkeit, diese Schlüssel zentral zu verwalten und ggf. bei Kompromittierung zurückzuziehen.
Ein konkretes Angriffsszenario ist jetzt erst mal damit nicht verbunden, aber es beschädigt das Vertrauen in die Paketverwaltung. Das ist natürlich ein bisschen abstrakt, deshalb muss man noch mal einen Blick auf die Bedeutung der Paketquellen werfen.
Die Integrität der Paketverwaltung ist ein wesentlicher Baustein in der Linux-Sicherheit. Software ist bei Linux (abgesehen von Flatpak und Snap) nicht in irgendwelche Sandboxen eingesperrt oder durch ein ausgefeiltes Rechtesystem isoliert. Anwender vertrauen darauf, dass die Integrität der Paketquellen gewährleistet ist und gültig signierte Pakete vertrauenswürdig sind.
Das ist kein Problem in der Kategorie „Ferner liefen“, denn RPM ist der Standard bei den beiden wichtigsten Enterprise-Distributionen RHEL und SLE. Mit Fedora und openSUSE greifen auch populäre Community-Distributionen darauf zurück.
Warum Baustelle Linux-Sicherheit?
Der Vorfall passt in eine Reihe von Problemen und Beobachtungen. Linux-Anwender und Linux-Entwickler sind in den letzten Jahren oft in eine Haltung bräsiger Selbstzufriedenheit verfallen. Probleme mit Sicherheit hatten schließlich immer nur die anderen.
Die Welt hat sich seitdem weiter gedreht und in anderen Betriebssystemen wurden Sicherheitskonzepte eingebaut, die es für Linux so in der Form nicht gibt. Matthew Garrett hat deshalb bereits 2017 auf der Guadec versucht, die Linux-Gemeinschaft aufzurütteln. Die Auswirkungen waren eher bescheiden.
Das traurige ist: Mit OpenPGP für die Signierung, AppArmor, SELinux, guten Firewall-Lösungen, Sandbox-Konzepten und all diesen Sachen hat Linux starke Lösungen. Nur leider werden die wenigsten davon standardmäßig durch die großen Distributionen eingesetzt und auch konsequent genutzt.
Wie sehr hier Linux in der Aufmerksamkeit unter dem Radar läuft und wie wenig Problembewusstsein bei den Entwicklern und Anwender vorherrscht, kann man sich leicht vor Augen führen, wenn man sich vorstellt ein vergleichbares Problem hätte macOS oder Windows getroffen. Häme und Aufschrei wären sicher gewaltig gewesen.
Zusammengefasst
Ein bisschen weniger Selbstzufriedenheit täte im Bereich der Linux-Sicherheit ganz gut. Es ist keine Katastrophe und dieses konkrete Problem sicher auch nicht, aber es sollte ein Weckruf sein, die Leerstellen anzuschauen und Abhilfe zu schaffen. Viele Lösungen sind da, sie müssen nur konsequent und konsistent genutzt werden.
> Das ist kein Problem in der Kategorie „Ferner liefen“, denn RPM ist der Standard bei den beiden wichtigsten Enterprise-Distributionen RHEL und SLE.
Theoretisch ist RPM auch der Standard in der Linux Standard Base (dem eigens für Linux ersonnenen POSIX-Ersatz), aber da sich Linuxer ja nicht mal an ihre eigenen Standards halten … 😉
Zu macOS habe ich keine Erfahrung, aber MS Windows Update w/ or w/o WSUS hat schon ähnliche Klopper gebracht (keine Überprüfung von Signaturen/fehlendes Cert Pinning für https). Was das RPM Disaster aber in keiner Weise rechtfertigt.
Signaturverfahren/-prozesse ohne Revocation Lists zu implementieren ist allerdings an Bräsigkleit kaum zu überbieten – genauso, dass dies jetzt erst publik wird…
Guter Artikel! Nur den letzten Absätzen kann ich nicht zustimmen. Welchen Beleg gibt es durch diese Sicherheitslücke für die extrem allgemeine Aussage: „wie wenig Problembewusstsein bei den Entwicklern und Anwender vorherrscht“. Auch der Begriff „Selbstzufriedenheit“ ist eher beleidigend, wenn er nicht durch Fakten getragen wird.
Ich hatte doch auf die Debatte von 2017 hingewiesen?! Was hat sich denn seitdem getan, das von mehr Problembewusstsein zeugt?
Wie immer werde ich durch den polemischen Clickbait Titel geködert. Ich glaube aber du liegst falsch. Ich nutze seit mehreren Jahren openSUSE und da läuft nach ein paar Jahren gerne mal ein Zertifikat eines Repositories ab, was dann zu nervigen aber nötigen Fehlermeldungen führt bis man die Änderung akzeptiert.
Man muss nicht jeden Titel gleich mit dem Schlagwort „Clickbait“ versehen, das ist nämlich was anderes. Wo hält der Artikel nicht was der Titel verspricht?
Zum Inhalt:
Bist du sicher, dass es sich bei deiner Beobachtung nicht um eine Funktion von Zypper handelt?