robertdfrench/ifuncd-upGNU IFUNC is the real culprit behind CVE-2024-3094
I see you jokers on [the orange website][hn] are giving me a hard time. I will make a few choice responses below, but first I offer a challenge: I will send $500 of my own money to the first person who can demonstrate this attack without ifunc. I am genuinely interested, and willing to pay to for the enlightenment. Fork this repo and submit a PR with your working PoC, I will solicit your mailing address privately if you win. Now for responses:
This is barking up the wrong tree.
Kid, I live in the wrong tree, I can bark at whoever I want.
It was not essential to the exploit,
You're not essential to the exploit!
There is always selinux if we want to add protection against arbitrary code running as root.
Once loaded, this attack did not need to cross any further syscall boundaries. So yes, we could have constrained a "bonus" root session, but we still would have had uninvited guests on the machine!
What is this, Bilbo's birthday?? No entrance except on party business!!
- IFUNC is hardly the only way to run code before main.
But it is an unnecessary way to run code before memory protection is set up
- The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process,
We can mprovise with mprotect! See the last sentence above the Modifying LD_PRELOAD subsection.
Yeah, this blog is misguided.
Excuse me this blog was unguided. I did all of these shenanigans myself! No one tricked me into being this stupid.
IFUNC should be implemented by [the client] software itself,
@CountWSS 💯 hell yeah
a series of blatant process failures from Github maintainer through ...
This is the only point I will respond to in earnest:
I think it is extraordinarily unfair to the xz-utils maintainer and quite dangerous to the community to think about this as beginning with a mistake on his part. It began with no one giving a shit about helping maintain this project. The attacker depended on ifunc as a technical vulnerability and our collective negligence of xz-utils as a social vulnerability. I think it is shameful to see Mr. Collin's actions as anything other than a heroic, years-long dedication to community service.
Also Bruce Schneier agrees with me so... hate it for ya, your argument's toast.
The language may have been harsher than it needed to
You aren't gonna believe how much my friends made me water this down first.
Linux distributions should not think so highly of themselves as to expect OpenBSD to conform and adapt to their mess
@debazel!!! Me gusta.
What complete horseshit.
Okay, that part's accurate.
Why you should stop blaming xz-utils for [CVE-2024-3094][nvd]. Also check out my ETSA Talk!
CVE-2024-3094, more commonly known as "The xz-utils backdoor", was a near miss for global cybersecurity. Had this attack not been discovered in the nick of time by [Andres Freund][freund], most of our planet's SSH servers would have begun granting root access to the party behind this attack.
Unfortunately, too much analysis has focused on how [malicious code][JiaT75] made its way into the xz-utils repo. Instead, I'd like to argue that two longstanding design decisions in critical open source software are what made this attack possible: [linking OpenSSH against SystemD][biebl], and the existence of [GNU IFUNC][sourceware].
Before You Start: Much of this discussion deals with the intricacies
of dynamic linking on Linux. If you need a refresher, check out
dynamic_linking.md.
There are tons of good writeups outlining the high level details of the xz-utils backdoor, like Dan Goodin's [What we know about the xz Utils backdoor that almost infected the world][goodin1] and Sam James' [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam] gist. We don't need to rehash all that here, so the purposes of this article, here is a very coarse recap:
flowchart TD
G["GNU IFUNC"]
A["OpenSSH (OpenBSD)"]
B["Portable OpenSSH<br/>(Linux / macOS / etc)"]
C[OpenSSH + IFUNC]
D[xz-utils]
E["SystemD (Linux)"]
A -->|Remove OpenBSD specifics| B
B -->|Add SystemD specifics| C
D --> E
E --> C
C --> F["Mayhem"]
G --> D
The short answer is that they have to. OpenSSH is developed by the OpenBSD community, for the OpenBSD community, and they do not give a flying Fedora about Linux. The [Portable OpenSSH][mindrot] project is a best-effort collection of patches which replace OpenBSD-specific components with generic POSIX components, and some platform-specific code where applicable. The software supply-chain for SSH ends up looking something like this in practice:
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
OpenBSD's version of OpenSSH is upstream from everything else, and most improvements to it come from within the OpenBSD community. These changes flow downstream to the Portable OpenSSH project, which attempts to re-implement new features in ways that aren't specific to OpenBSD. This is what allows SSH to work on platforms like Linux, macOS, FreeBSD, and even Windows.
But it doesn't stop there. Some operating systems apply further
customization beyond what Portable OpenSSH provides. For example, Apple
adds the [--apple-use-keychain][keith] flag to ssh-add to help it
integrate with the macOS password manager.
In the case of CVE-2024-3094, Fedora and Debian maintained their own
[SystemD patches][biebl] for their forks of OpenSSH in order to fix a
[race condition around sshd restarts][schmidt]. So the actual supply
chain for SSH began to look like this:
flowchart TD
A[OpenSSH]
B[Portable OpenSSH]
C[Debian SSH]
D[Fedora SSH]
A-->B
B-->C
B-->D
C<-->|SystemD Patches|D
These patches never went into Portable OpenSSH, because the Portable OpenSSH folks were ["not interested in taking a dependency on libsystemd"][djmdjm]. And they never went into upstream OpenSSH, because OpenBSD doesn't have any need to support SystemD.
This seems harmless enough, but it's an example of a much larger problem in Open Source, particularly in Linux: critical components of the operating system are developed by people who don't know each other, and don't talk to each other.