Ein Blog

xz wurde gebackdoort. Die Story ist schon ganz interessant. Aufgefallen ist es, weil die gebackdoorte Version Performanceprobleme hatte. Die Version mit Backdoor ist noch nicht wirklich verbreitet worden. Bei Debian haben anonyme Accounts darauf gedrängt, das Update mit der Backdoor anzunehmen. Eine ähnliche Geschichte, bei der die Version schnell released werden sollte, berichtet auch ein Fedora-Maintainer. Bei letzterem war es sogar so, dass der Fedora-Maintainer mit dem xz-Maintainer noch zusammen Speicherprobleme gelöst hat, damit sie die Version releasen können. Die Speicherprobleme kamen von genau der Backdoor. Ja, wirklich!

Die Backdoor passiert beim Bauen der tarball. Der scheinbare Backdoor-Autor hat im Vorfeld auf der Projektseite auch eine spannende Notiz hinterlassen:

Note: GitHub automatically includes two archives Source code (zip) and Source code (tar.gz) in the releases.
These archives cannot be disabled and should be ignored.

Das wird ja immer goldiger! In einem anderen Commit hat er die SECURITY.md-Policy “vereinfacht”:

 You may submit a report by emailing us at
 [xz@tukaani.org](mailto:xz@tukaani.org), or through
 [Security Advisories](https://github.com/tukaani-project/xz/security/advisories/new).
-While both options are available, we prefer email. In any case, please
-provide a clear description of the vulnerability including:
-
-- Affected versions of XZ Utils
-- Estimated severity (low, moderate, high, critical)
-- Steps to recreate the vulnerability
-- All relevant files (core dumps, build logs, input files, etc.)
+While both options are available, we prefer email.

Der Autor ist auch zu Googles OSS-fuzz hingegangen und hat das Feature deaktiviert, auf das die Backdoor zurückgreift, damit es nicht durch’s Fuzzen auffällt.

Zu der Geschichte kommen immer noch mehr Details ran. Auf HN werden sie in den Kommentaren gesammelt.

Was mich zu der Frage bringt: Angenommen, der GH-User hat diese Commits willentlich getätigt. Hat er dafür rechtliche Konsequenzen zu befürchten? Wie will man das machen? In diesem Fall wurde es noch bemerkt. Wenn daraus keine Konsequenzen folgen, hält das andere Maintainer kaum davon ab, dasselbe zu tun.

Update:

FAQ on the xz-utils backdoor.
Stand 2024-03-29:

TL;DR: We think the following things need to be true for your system to be vulnerable:

  • You need to be running a rolling-release distro and updating religiously
  • You need to be running a distro that uses glibc and systemd
  • You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma)
  • You need to have your SSH port exposed to the public internet

Das FAQ ist wirklich gut und erläutert auch noch ein paar technische Umsetzungen. Hier gibt es noch eine Timeline: Everything I Know About the Xz Backdoor.

Update:

Bei der Analyse der installierten Backdoor gab es mittlerweile einige Fortschritte. Anfangs dachte man, dass RSA_public_decrypt gehookt würde, um einen Auth-Bypass zu erreichen. Mittlerweile wissen wir: Das war eine RCE.
Die Backdoor hat einen Ed448-Public-Key hartkodiert. Mit dem wird beim Anklopfen an die Hintertür überprüft, ob es sich um einen legitimen Angreifer handelt, durch einen Signatur-Check. Falls ja, wird die übermittelte Payload ausgeführt. Falls nein wird einfach weitergemacht, wie sonst auch. Das bedeutet: Man kann ein betroffenes System nicht durch sein äußerliches Verhalten erkennen - es sei denn, man hat den private Key zu der Backdoor. Um zu erkennen, ob ein System betroffen ist, funktioniert also kein Netzwerkscanner. Stattdessen muss das System lokal Dateien überprüfen.

Es wurde übrigens nicht nur bei Fedora und Debian versucht, das Paket unterzubringen. Auch bei Ubuntu wurde versucht, es vor dem Freeze aufzunehmen. Wir sind quasi durch Zufall einem Generalschlüssel für’s Internet ausgewichen.

Update:
Auf der Webseite des Maintainers gibt es jetzt auch eine Status-Seite: https://tukaani.org/xz-backdoor

In diesem Commit wurde Landlock deaktiviert. Wo genau ist das passiert? Hiermit. In diesem Commit kam es in’s Repo.

Update:

Hier eine Analyse der Obfuscation der Bash-Stage. Die Commit-Zeiten wurden auch schon analyisert.

Update:

Hier gibt es schon tooling, um die Backdoor selbst auszunutzen (wenn man die Backdoor mit seinem eigenen Key patcht).