XZ-Utils-Lieferkettenangriff (CVE-2024-3094)

CVE-2024-3094 betraf XZ-Utils-Tarballs 5.6.0/5.6.1. Das Risiko hing vom Distributions-Build ab; betroffene Pakete ermitteln und ersetzen.^{[1], [3], [4], [5], [6]}

CVSS-Vektor

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H^[9]

💡 Einfache Erklärung (ELI5)

Stellen Sie sich das Quellcode-Repository als öffentliches Rezept und das Release-Archiv als versiegelte Zutatenkiste vor. Selbst wenn das Rezept richtig aussieht, prüft die Küche Siegel und Lieferschein. Der gleiche Name auf der Kiste reicht nicht, um sie direkt in die Produktion zu geben. Ein über einen getrennten Kanal authentifiziertes Manifest kann eine ausgetauschte Kiste erkennen, aber selbst eine gültige Herstellersignatur beweist nicht, dass eine autorisierte Kiste harmlos ist: Die kompromittierten XZ-Kisten waren offizielle Releases. Ersetzen Sie betroffene Pakete gemäß den Distributionshinweisen; verwenden Sie die Manifestprüfung nur als zusätzlichen Schutz gegen Austausch.^{[5], [6]}

Kernkonzepte & Begriffe

Release-Archiv: Ein zur Installation oder Paketierung veröffentlichtes Quellcode-Archiv. Es kann von Dateien aus dem Repository abweichen und muss daher als eigenes Artefakt geprüft werden.^{[3], [4], [6]}
Build-Provenance: Der Nachweis, aus welchem geprüften Quellcode, welchen Build-Schritten und von welchem Herausgeber ein Artefakt stammt. Er ermöglicht eine fundierte Vertrauensentscheidung.^{[5], [6]}
Artefaktprüfung: Der Vergleich von Hash oder Signatur eines Artefakts mit einem erwarteten Wert, der über einen unabhängigen vertrauenswürdigen Kanal bezogen wurde.

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-506

Vorfall-Zeitstrahl

24. Februar 2024

XZ 5.6.0 wurde veröffentlicht; die spätere Stellungnahme des Projekts sagt, dass sein Release-Archiv eine Hintertür enthielt.^{[3], [6]}

9. März 2024

XZ 5.6.1 wurde veröffentlicht; dieselbe Stellungnahme sagt, dass sein Release-Archiv eine Hintertür enthielt.^{[4], [6]}

Vor dem 29. März 2024

Freund berichtete über ein injiziertes Build-Skript in Verteilarchiven, das in der entsprechenden Upstream-Datei fehlte, nachdem ungewöhnliche SSH-CPU-Nutzung und Valgrind-Fehler die Untersuchung ausgelöst hatten.^{[5], [6]}

29. März 2024

Andres Freund veröffentlichte den Bericht über das Problem.^[5]

Schritt-für-Schritt Angriffsablauf

Schritt 1

Repository und Verteilarchiv sind nicht identisch

Die öffentliche Analyse beschreibt Build-Skript-Änderungen im verteilten Archiv, die nicht in der entsprechenden Upstream-Repository-Datei standen. Die Prüfung von Repository-Commits allein beweist die Sicherheit eines Archivs nicht.^{[5], [6]}

Schritt 2

Die Auswirkung hängt vom Build-Pfad ab

Das Problem trat unter bestimmten Paketierungs- und Build-Bedingungen auf. Der offizielle Bericht erklärt, dass ein Build aus Git den betreffenden Code nicht einfügt; die Reichweite darf nicht auf jede XZ- oder Linux-Installation verallgemeinert werden.^{[5], [6]}

Schritt 3

Auffälligkeiten lösten die Untersuchung aus

Andres Freund berichtete über ungewöhnliche CPU-Nutzung und Valgrind-Fehler bei einem SSH-Prozess. Diese beobachtbaren Signale führten zur Untersuchung und Offenlegung.^[5]

Schritt 4

Reaktion beginnt mit Austausch und Prüfung

Behandeln Sie den Fall als Vorfall mit betroffenen Paketen und Build-Provenienz. Folgen Sie den Distributionshinweisen und ersetzen Sie betroffene Pakete. Prüfen Sie bei künftigen Artefakten Provenienz und Signaturen: So lässt sich ein Austausch erkennen, nicht aber beweisen, dass ein autorisiertes Release harmlos ist.^{[1], [6]}

Quellcode: Verwundbar vs. Sicher

VERWUNDBARE IMPLEMENTIERUNG

# Übernimmt eine heruntergeladene Build-Eingabe, ohne ihre Identität nachzuweisen.
from pathlib import Path

def stage_release(artifact: Path, build_inputs: Path) -> None:
    build_inputs.joinpath(artifact.name).write_bytes(artifact.read_bytes())

# Eine erfolgreiche Kopie beweist nicht, dass dieses Archiv der
# geprüften Veröffentlichung oder einem vertrauenswürdigen Manifest entspricht.

GEHÄRTETER SICHERHEITS-PATCH

# Beispielhafte Freigabe: prüft erwartetes SHA-256 aus einem vertrauenswürdigen Manifest.
import hashlib
import hmac
from pathlib import Path

def verify_release(artifact: Path, expected_sha256: str) -> None:
    digest = hashlib.sha256(artifact.read_bytes()).hexdigest()
    if not hmac.compare_digest(digest, expected_sha256.lower()):
        raise ValueError("Release-Artefakt entspricht nicht dem vertrauenswürdigen Manifest")

# Beziehen Sie expected_sha256 über einen getrennt authentifizierten Release-Prozess
# und rufen Sie verify_release auf, bevor das Archiv Build-Eingabe wird.

# Dies erkennt einen Austausch, kein autorisiertes, aber bösartiges Release; folgen Sie den Hinweisen für betroffene Pakete.

Checkliste für Engineering & Systemsicherheit

✓Vergleichen Sie heruntergeladene Release-Archive mit einem Hash oder einer Signatur aus einem getrennt authentifizierten Kanal; ein erfolgreicher Download ist kein Herkunftsnachweis.^{[1], [6]}
✓Dokumentieren Sie für reproduzierbare Builds Quellrevision, Build-Umgebung und Artefakt-Hash; vergleichen Sie unabhängige Build-Ergebnisse bei Änderungen kritischer Abhängigkeiten.
✓Prüfen Sie Build-Skripte, Paketierungsregeln und Testartefakte so streng wie Anwendungscode und dokumentieren Sie Herkunft und Integrität unerklärlicher binärer Testdaten.
✓Verlangen Sie mindestens zwei Freigaben für Änderungen an Release-Werkzeugen, CI-Konfiguration und Paketierungsschritten und bewahren Sie nachverfolgbare Aufzeichnungen auf.^{[5], [6]}
✓Ermitteln Sie betroffene Pakete und Versionen anhand der Hersteller- und Distributionshinweise und prüfen Sie die Herkunft nach dem Austausch erneut.
✓Nehmen Sie unerklärliche CPU-Nutzung, Leistungseinbrüche und Fehler von Speicherprüfungen in die Untersuchung auf und bewahren Sie überprüfbare Belege auf.^[5]