Das xz-Problem und ein Blick auf unsere Supply-Chain-Strategie

Kaum ein Tag vergeht inzwischen, ohne dass wir in den IT-News über Sicherheitslücken und dringende Patches in bekannten Softwareprodukten informiert werden. Und so nehmen viele von uns Sicherheitsprobleme in Software oft hin wie schlechtes Wetter.

Allerdings elektrisiert ein Vorfall der jüngeren Zeit die Sicherheitsforscher: die Injektion einer überaus gut getarnten und absichtlich plazierten Backdoor in die Kompressionsbibliothek xz, die von vielen Softwareprojekten verwendet wird. Das Perfide: die Backdoor war auf eine völlig andere Softwarekomponente ausgerichtet, nämlich Secure Shell (openssh) im Zusammenspiel mit systemd, und entfaltete nur in dieser Kombination ihre Wirkung.
Der offensichtlich über einen langen Zeitraum zielgerichtet vorbereitete Angriff nutzte die Überlastung des Projekt-Maintainers aus und erarbeitete sich geduldig commit-Rechte auf dem xz-Repository.
Wäre ein resultierender Seiteneffekt nicht eher zufällig bei Performance-Tests bemerkt worden, hätte diese Lücke über die Zeit sicher Millionen Linux-Systeme für die dahinter stehende Gruppe angreifbar gemacht. Ein Desaster von epischen Ausmaßen wurde gerade so verhindert.

Dieser Vorfall betont aufs Neue die besondere Bedeutung der "Supply Chain", also die von einem Software-Produkt verwendeten Abhängigkeiten in Form von oft hunderten oder tausenden von separat verwalteten Bibliotheken und Toolkits, die teilweise sogar nur indirekt über mehrere Ebenen hinweg verwendet werden.

Wie gehen wir damit für unsere eigenen Produkte um? Auch OpenXPKI verwendet eine große Zahl an Bibliotheken. Wir haben uns schon vor einigen Jahren entschieden, die Enterprise-Edition von OpenXPKI als all-in-one Bundle auszuliefern und möglichst keine vom Betriebssystem verwalteten externen Abhängigkeiten zu nutzen. So verwendet der Build-Prozess für die Enterprise-Pakete eine manuell kuratierte Liste der zu paketierenden Abhängigkeiten, verbunden mit einem lokalen Spiegel dieser Software-Komponenten auf unseren Build-Systemen.
Vor unseren Releases werfen wir einen kritischen Blick auf diese Abhängigkeiten und ihre Release-Notes, um zu entscheiden, ob wir ein Upgrade in unseren Build-Prozess aufnehmen. So können wir exakt definieren, welche Software-Versionen der Abhängigkeiten von uns paketiert und verteilt werden.

Insgesamt sind Supply-Chain-Angriffe jedoch schwer in den Griff zubekommen. Niemand kann für ein komplexes Softwareprodukt umfangreiche Source-Code-Audits über jede eingebundene Bibliothek und jede einzelne von den Maintainern vorgenommene Änderung durchführen. Und so müssen wir uns alle ein wenig darauf verlassen, dass die Schutzmechanismen der OpenSource-Community wie bisher funktionieren. Bei xz und bei Heartbleed hat das bisher glücklicherweise gut funktioniert. Hoffen wir, dass die Community weiterhin so aufmerksam bleibt!