robertdfrench/ifuncd-upGNU IFUNC ist der wahre Schuldige hinter CVE-2024-3094
Ich sehe schon, ihr Scherzkekse auf [der orangen Website][hn] macht mir das Leben schwer. Ich werde unten ein paar ausgewählte Antworten geben, aber zuerst biete ich eine Herausforderung an: Ich schicke 500 $ von meinem eigenen Geld an die erste Person, die diesen Angriff ohne ifunc demonstrieren kann. Ich bin aufrichtig interessiert und bereit, für die Erleuchtung zu zahlen. Forkt dieses Repo und reicht einen PR mit eurem funktionierenden PoC ein; ich erfrage eure Postadresse privat, falls ihr gewinnt. Nun zu den Antworten:
Das ist der falsche Baum, an dem du bellst.
Kind, ich lebe im falschen Baum, ich kann anbellen, wen ich will.
Es war nicht wesentlich für den Exploit,
Du bist nicht wesentlich für den Exploit!
Es gibt immer selinux, wenn wir Schutz gegen beliebigen Code, der als root läuft, hinzufügen wollen.
Einmal geladen, musste dieser Angriff keine weiteren Syscall-Grenzen mehr überschreiten. Also ja, wir hätten eine „Bonus“-Root-Session einschränken können, aber wir hätten trotzdem ungebetene Gäste auf der Maschine gehabt!
Was ist das, Bilbos Geburtstag?? Kein Zutritt außer für Partyangelegenheiten!!
- IFUNC ist kaum der einzige Weg, Code vor main auszuführen.
Aber es ist ein unnötiger Weg, Code bevor der Speicherschutz eingerichtet ist auszuführen.
- Die Alternative, die sie präsentieren, ist wohl weniger sicher, weil der Funktionszeiger für die Lebensdauer des Prozesses beschreibbar bleibt,
Wir können mit mprotect improvisieren! Siehe den letzten Satz über dem Unterabschnitt Modifying LD_PRELOAD.
Ja, dieser Blog ist fehlgeleitet.
Entschuldigung, dieser Blog war ungeleitet. Ich habe all diese Eskapaden selbst angestellt! Niemand hat mich dazu verleitet, so dumm zu sein.
IFUNC sollte von [der Client-]Software selbst implementiert werden,
@CountWSS 💯 verdammt ja
eine Reihe offensichtlicher Prozessfehler vom Github-Maintainer bis hin zu ...
Das ist der einzige Punkt, auf den ich ernsthaft antworten werde:
Ich denke, es ist dem xz-utils-Maintainer gegenüber außerordentlich unfair und für die Community ziemlich gefährlich, dies als beginnend mit einem Fehler seinerseits zu betrachten. Es begann damit, dass sich niemand darum scherte, bei der Wartung dieses Projekts zu helfen. Der Angreifer verließ sich auf ifunc als technische Schwachstelle und auf unsere kollektive Vernachlässigung von xz-utils als soziale Schwachstelle. Ich halte es für beschämend, die Handlungen von Herrn Collin als etwas anderes zu sehen denn als heroische, jahrelange Hingabe an den Dienst an der Gemeinschaft.
Außerdem stimmt Bruce Schneier mir zu also... Pech für dich, dein Argument ist erledigt.
Die Sprache mag härter gewesen sein als nötig
Du wirst nicht glauben, wie sehr meine Freunde mich gezwungen haben, das erst abzumildern.
Linux-Distributionen sollten nicht so von sich eingenommen sein zu erwarten, dass OpenBSD sich anpasst und sich ihrem Chaos fügt
@debazel!!! Me gusta.
Was für ein kompletter Pferdemist.
Okay, dieser Teil ist zutreffend.
Warum du aufhören solltest, xz-utils für [CVE-2024-3094][nvd] die Schuld zu geben. Schau dir auch meinen ETSA Talk an!
CVE-2024-3094, besser bekannt als „Der xz-utils-Backdoor“, war ein Beinahe-Unfall für die globale Cybersicherheit. Wäre dieser Angriff nicht in letzter Sekunde von [Andres Freund][freund] entdeckt worden, hätten die meisten SSH-Server unseres Planeten begonnen, der hinter diesem Angriff stehenden Partei Root-Zugriff zu gewähren.
Leider hat sich zu viel der Analyse darauf konzentriert, wie [bösartiger Code][JiaT75] seinen Weg in das xz-utils-Repo gefunden hat. Stattdessen möchte ich argumentieren, dass zwei seit Langem bestehende Designentscheidungen in kritischer Open-Source-Software diesen Angriff möglich gemacht haben: [das Linken von OpenSSH gegen SystemD][biebl] und die Existenz von [GNU IFUNC][sourceware].
Bevor du anfängst: Ein Großteil dieser Diskussion befasst sich mit den Feinheiten des dynamischen Linkens unter Linux. Wenn du eine Auffrischung brauchst, schau dir dynamic_linking.md an.
Es gibt jede Menge gute Artikel, die die Details auf hoher Ebene des xz-utils-Backdoors beschreiben, wie Dan Goodins [What we know about the xz Utils backdoor that almost infected the world][goodin1] und Sam James' Gist [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam]. Wir müssen das hier nicht alles wiederkäuen, daher ist für die Zwecke dieses Artikels hier eine sehr grobe Zusammenfassung:
## Warum modifizieren Linux-Distributionen OpenSSH?
Die kurze Antwort ist, dass sie es müssen. OpenSSH wird von der
OpenBSD-Community für die OpenBSD-Community entwickelt, und sie scheren
sich einen feuchten Kehricht um Linux. Das [Portable OpenSSH][mindrot]-Projekt ist eine
Best-Effort-Sammlung von Patches, die OpenBSD-spezifische
Komponenten durch generische POSIX-Komponenten und, wo zutreffend, durch
plattformspezifischen Code ersetzen. Die Software-Lieferkette für SSH sieht
in der Praxis in etwa so aus:```mermaid
flowchart TD
subgraph OpenBSD Folks
A[OpenBSD]
B[OpenSSH]
H[improvements]
end
B-->A
A-->H
H-->B
B-->C
C[Portable OpenSSH]
subgraph Debian Folks
D[Debian SSH]
G[improvements]
end
C-->D
D-->G
G-->C
subgraph Fedora Folks
J[Fedora SSH]
K[improvements]
end
C-->J
J-->K
K-->C
Die OpenSSH-Version von OpenBSD ist allen anderen vorgelagert, und die meisten Verbesserungen daran stammen aus der OpenBSD-Community. Diese Änderungen fließen stromabwärts zum Portable-OpenSSH-Projekt, das versucht, neue Funktionen so neu zu implementieren, dass sie nicht OpenBSD-spezifisch sind. Dadurch kann SSH auf Plattformen wie Linux, macOS, FreeBSD und sogar Windows funktionieren.
Doch dabei bleibt es nicht. Einige Betriebssysteme nehmen weitere Anpassungen vor, die über das hinausgehen, was Portable OpenSSH bietet. Beispielsweise fügt Apple das Flag [--apple-use-keychain][keith] zu ssh-add hinzu, um die Integration mit dem macOS-Passwortmanager zu ermöglichen.
Im Fall von CVE-2024-3094 pflegten Fedora und Debian ihre eigenen [SystemD-Patches][biebl] für ihre OpenSSH-Forks, um eine [Race Condition bei sshd-Neustarts][schmidt] zu beheben. Die tatsächliche Lieferkette für SSH begann also so auszusehen:```mermaid
flowchart TD
A[OpenSSH]
B[Portable OpenSSH]
C[Debian SSH]
D[Fedora SSH]
A-->B
B-->C
B-->D
C<-->|SystemD Patches|D
Diese Patches wurden nie in Portable OpenSSH aufgenommen, weil die
Portable-OpenSSH-Leute ["nicht daran interessiert waren, eine Abhängigkeit
von libsystemd einzugehen"][djmdjm]. Und sie wurden nie in das
Upstream-OpenSSH aufgenommen, weil OpenBSD keinerlei Bedarf hat, SystemD
zu unterstützen.