Eine Analyse der xz-Hintertür, Teil 4

Inhaltsverzeichnis

Der Angreifer hat es geschafft, dass die xz-Bibliothek liblzma unter Debian und RedHat ein bösartiges Object-File einschließt: liblzma_la-crc64-fast.o. Nun lassen wir die Compilier- und Paketbauphase hinter uns und sehen uns an, was der eingeschleuste Code bei Opfern anrichtet. Mit knapp 90 KByte ist das Object-File ein ziemlicher Brocken und nicht nur deshalb sehr schwer zu analysieren.

Wir wenden uns zunächst der einfacheren Frage zu, unter welchen Umständen Code in liblzma_la-crc64-fast.o überhaupt zur Ausführung kommt. Wie im vergangenen Teil beschrieben, manipuliert die Hintertür beim Paketbau die Quellcodedateien crc64_fast.c und crc32_fast.c im Verzeichnis src/liblzma/check/. Konkret passt sie darin die Funktionen crc64_resolve() und crc32_resolve() an, sodass bei deren Aufruf letztlich die Funktion _get_cpuid() aus der Hintertür ausgeführt wird.

Eine Analyse der xz-Hintertür

• Eine Analyse der xz-Hintertür, Teil 1
• Eine Analyse der xz-Hintertür, Teil 2
• Eine Analyse der xz-Hintertür, Teil 3
• Eine Analyse der xz-Hintertür, Teil 4

Bei den …resolve()-Funktionen handelt es sich um ifunc-Resolver, wie der Name nahelegt. Mit "GNU indirect functions" (ifunc) können Entwickler dynamisch entscheiden, welchen Code eine Funktion nutzen soll. Das erlaubt beispielsweise, hochoptimierten Code auszuliefern: Entwickler können besonders performancerelevante Funktionen in verschiedenen Versionen für verschiedene Prozessorarchitekturen programmieren. Per ifunc-Resolver gestattet der dynamische Linker dann dem Programm zur Laufzeit, die Implementierung zu wählen, die am besten zum aktuellen System passt.

Das war die Leseprobe unseres heise-Plus-Artikels "Eine Analyse der xz-Hintertür, Teil 4". Mit einem heise-Plus-Abo können sie den ganzen Artikel lesen und anhören.