Using IFUNC to patch sshd was kind of elegant, it achieved rootkit like behaviour with a pre-existing mechanism. And sure, it might be possible for a secure daemon like sshd to drop enough privileges that it could protect itself from a malicious dynamically linked library.
But IFUNC was not required, neither was systemd. The game was lost as soon as the attacker had arbitrary code installed in a semi-common library. It doesn't have to get linked directly with sshd, it only needed to be linked into any program running as root, at least one time.
Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.
IFUNC, systemd, and the patched openssh are all irrelevant to the issue, that was simply the route this attacker took to leverage their foothold in libxz. There are thousands of potential routes the attacker could have taken, and we simply can't defend from all of them.
1) IFUNC is hardly the only way to run code before main.
2) The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process, whereas with IFUNC the GOT will eventually be made immutable (or can be... not sure if that's the default behavior). In general function pointers aren't great for security unless you explicitly make the memory backing the pointer(s) unwritable, which at least is easier to do for a global table than it is for things like C++ vtables (because there's the extra indirection through data pointers involved to get to the table).
Yeah, this blog is misguided. As a higher level criticism: it's confusing[1] the technical details with the payload with the exploit chain that deployed it.
The interesting thing is obviously not that you can get code to run at high privilege level by modifying a system component. I mean, duh, as it were.
The interesting thing is that the attackers (almost) got downstream Linux distros to suck down and deploy that malicious component for them. And that's not down to an oddball glibc feature, it happened because they got some human beings to trust a malicious actor. GNU glibc can't patch that!
> The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process
The article mentions this, and also points to mprotect which you can use to protect the pointer.
Why people jump to criticize without reading first? BTW, you can ask an LLM to check your critique, before posting, if you don't want to read the text.
IFUNC should be implemented by software itself,
like switching functions on runtime/compile checks.
Why bother having a slower, insecure version that is less
flexible than a function pointer? I have to agree with author.
Glibc is filled with even more nasty hacks ripe for new exploits.
I agree so much and wished this was the main focus of the debate. It's more a question of why does this exist in the first place and not of how did they abuse it. Building only from source is the minimum required transparency and a CI/CD pipeline able to manipulate the artifact before release takes this away. I remember the outrage, when serde (i think it was) wanted to ship parts as pre-compiled binaries for build performance reasons...
Some solaris engineer got a little too clever and decided that the modular part of the the auth system needed to be dynamic libs. Now it's all in one process space, hard to understand, hard to debug and fragile.
I really like openbsd's bsdauth, I don't know if it is actually any better than pam but because it is moduler at the process level it is possible for mere mortals to debug and make custom auth plugins. Sadly only obsd actually uses it. https://man.openbsd.org/login.conf.5#AUTHENTICATION
Debian did not link OpenSSH with a 1.5 million-line library, because one doesn't exist. The library is libsystemd, which is comparatively tiny, and it is tiny so that sane things like Type=notify services get supported in more places with less pushback.
Yes, it could be smaller, broken up to remove compression support [0], what have you. But you should criticize the things that are actually problems, not some made-up bullshit about the whole of systemd being linked into everything that talks to it.
> Great. TFA's author thinks he cherry picked a sentence to make the project look bad.
Err... What? It's just a factual, non-judgemental description. Unlike your comment, which goes out of its way to call systemd names for whatever reason. Which just makes me less interested in what you have to say. Most people who rely on appeal to emotion to that extent are not in the right.
> systemd is a monstrous codebase and there lies shitload of exploits in it. Either intentional or accidental.
And yet...
1. practically all hyperscalers use it
2. desktops
3. container images, that power everything from docker to kubernetes use it
It helps that it's actively maintained, battle-tested as hell, and widely audited.
Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
> It helps that it's actively maintained, battle-tested as hell, and widely audited.
Is it actually audited? Or is it like OpenSSL... everybody uses it, but nobody looks under the hood cause it's gross in there? (Or well, nobody looked before Heartbleed anyway)
> Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
Can you even imagine pypi or npm compromising ssh this way?
> 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.
What complete horseshit. I stopped reading there.
The OpenSSH Portable branch is maintained by OpenBSD developers and SystemD is a completely optional add-on so why on earth would they make it a dependency? If they didn't care about the Linux community they wouldn't develop this software *for free* for them. They can go write their own GNU SSH then.
It certainly doesn't help that there are 165+ definitions of what constitutes a "complete GNU+Linux system" some of which use SystemD and some which vow never to.
It's not the OpenBSD developers' fault some Linux distros use overly complex plumbing and can't agree on one standard for their OS unlike every other OS out there, including Windows.
The xz backdoor was a Debian and Red Hat issue because they maintained patches to fix problems of their own creation. No one else was affected. Why should the OpenBSD people care? It's not their problem.
The OP agrees with you... if you continue reading, they wrote
> These patches never went into Portable OpenSSH, because the Portable OpenSSH folks were ["not interested in taking a dependency on libsystemd"](link). And they never went into upstream OpenSSH, because OpenBSD doesn't have any need to support SystemD.
The language may have been harsher than it needed to and therefore could be more easily misunderstood, but I believe you are actually in agreement with them
It makes it sound even worse, cherry picking language like "not interested" as if the OpenBSD folks should shoulder blame for not being altruistic enough.
It reeks of trashing your benefactor, who gave you well-written free software, which you then made insecure with your own patches.
If you remove the roof of your car with a chainsaw and are inevitably injured later, is it the car manufacturer's fault they didn't offer that model as a convertible from the factory?
The better question is why are people still trying to assign blame all these years later? The IT world dodged a bullet but has moved on (and likely didn't learn from their mistakes as supply chain attacks are steadily increasing).
This is barking up the wrong tree.
Using IFUNC to patch sshd was kind of elegant, it achieved rootkit like behaviour with a pre-existing mechanism. And sure, it might be possible for a secure daemon like sshd to drop enough privileges that it could protect itself from a malicious dynamically linked library.
But IFUNC was not required, neither was systemd. The game was lost as soon as the attacker had arbitrary code installed in a semi-common library. It doesn't have to get linked directly with sshd, it only needed to be linked into any program running as root, at least one time.
Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.
IFUNC, systemd, and the patched openssh are all irrelevant to the issue, that was simply the route this attacker took to leverage their foothold in libxz. There are thousands of potential routes the attacker could have taken, and we simply can't defend from all of them.
1) IFUNC is hardly the only way to run code before main.
2) The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process, whereas with IFUNC the GOT will eventually be made immutable (or can be... not sure if that's the default behavior). In general function pointers aren't great for security unless you explicitly make the memory backing the pointer(s) unwritable, which at least is easier to do for a global table than it is for things like C++ vtables (because there's the extra indirection through data pointers involved to get to the table).
Yeah, this blog is misguided. As a higher level criticism: it's confusing[1] the technical details with the payload with the exploit chain that deployed it.
The interesting thing is obviously not that you can get code to run at high privilege level by modifying a system component. I mean, duh, as it were.
The interesting thing is that the attackers (almost) got downstream Linux distros to suck down and deploy that malicious component for them. And that's not down to an oddball glibc feature, it happened because they got some human beings to trust a malicious actor. GNU glibc can't patch that!
[1] Incorrectly, as you point out.
> The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process
The article mentions this, and also points to mprotect which you can use to protect the pointer.
Why people jump to criticize without reading first? BTW, you can ask an LLM to check your critique, before posting, if you don't want to read the text.
Yes but at best their "solution" is equally secure, not any better.
3 replies →
IFUNC should be implemented by software itself, like switching functions on runtime/compile checks. Why bother having a slower, insecure version that is less flexible than a function pointer? I have to agree with author. Glibc is filled with even more nasty hacks ripe for new exploits.
I agree so much and wished this was the main focus of the debate. It's more a question of why does this exist in the first place and not of how did they abuse it. Building only from source is the minimum required transparency and a CI/CD pipeline able to manipulate the artifact before release takes this away. I remember the outrage, when serde (i think it was) wanted to ship parts as pre-compiled binaries for build performance reasons...
Isn't it the same problem with pam.
Some solaris engineer got a little too clever and decided that the modular part of the the auth system needed to be dynamic libs. Now it's all in one process space, hard to understand, hard to debug and fragile.
I really like openbsd's bsdauth, I don't know if it is actually any better than pam but because it is moduler at the process level it is possible for mere mortals to debug and make custom auth plugins. Sadly only obsd actually uses it. https://man.openbsd.org/login.conf.5#AUTHENTICATION
seeing LD_PRELOAD in the "less-exploitable alternatives to GNU IFUNC" section was kind of funny
> By letting the linker run arbitrary code before main
As I know C++ allows running arbitrary code before main too - for constructors of global variables. Does it bring security risks too?
It does not, it's actually arbitrary code running during the dynamic loading process, i.e. before _start.
But what if I have a C++ dynamic library? Does it call constructors for global variables before _start function in the main program starts?
Well, also Unicode identifiers, a C11 spec bug, nobody cares to fix. Still in C26, because "users expect Unicode stability", esp. it's bugs.
Yes, that nefarious nation-state threat actor known as GNU IFUNC!
Curses, thwarted again!
[flagged]
Debian did not link OpenSSH with a 1.5 million-line library, because one doesn't exist. The library is libsystemd, which is comparatively tiny, and it is tiny so that sane things like Type=notify services get supported in more places with less pushback.
Yes, it could be smaller, broken up to remove compression support [0], what have you. But you should criticize the things that are actually problems, not some made-up bullshit about the whole of systemd being linked into everything that talks to it.
0: https://github.com/systemd/systemd/issues/32028
> Great. TFA's author thinks he cherry picked a sentence to make the project look bad.
Err... What? It's just a factual, non-judgemental description. Unlike your comment, which goes out of its way to call systemd names for whatever reason. Which just makes me less interested in what you have to say. Most people who rely on appeal to emotion to that extent are not in the right.
> systemd is a monstrous codebase and there lies shitload of exploits in it. Either intentional or accidental.
And yet...
1. practically all hyperscalers use it
2. desktops
3. container images, that power everything from docker to kubernetes use it
It helps that it's actively maintained, battle-tested as hell, and widely audited.
Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
> It helps that it's actively maintained, battle-tested as hell, and widely audited.
Is it actually audited? Or is it like OpenSSL... everybody uses it, but nobody looks under the hood cause it's gross in there? (Or well, nobody looked before Heartbleed anyway)
1 reply →
> Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
Can you even imagine pypi or npm compromising ssh this way?
2 replies →
xz-tools should scrap and reimplemented the code to the safer one , current one have safety and performance issue.
> Why do Linux Distros modify OpenSSH?
> 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.
What complete horseshit. I stopped reading there.
The OpenSSH Portable branch is maintained by OpenBSD developers and SystemD is a completely optional add-on so why on earth would they make it a dependency? If they didn't care about the Linux community they wouldn't develop this software *for free* for them. They can go write their own GNU SSH then.
It certainly doesn't help that there are 165+ definitions of what constitutes a "complete GNU+Linux system" some of which use SystemD and some which vow never to.
It's not the OpenBSD developers' fault some Linux distros use overly complex plumbing and can't agree on one standard for their OS unlike every other OS out there, including Windows.
The xz backdoor was a Debian and Red Hat issue because they maintained patches to fix problems of their own creation. No one else was affected. Why should the OpenBSD people care? It's not their problem.
The OP agrees with you... if you continue reading, they wrote
> These patches never went into Portable OpenSSH, because the Portable OpenSSH folks were ["not interested in taking a dependency on libsystemd"](link). And they never went into upstream OpenSSH, because OpenBSD doesn't have any need to support SystemD.
The language may have been harsher than it needed to and therefore could be more easily misunderstood, but I believe you are actually in agreement with them
It makes it sound even worse, cherry picking language like "not interested" as if the OpenBSD folks should shoulder blame for not being altruistic enough.
It reeks of trashing your benefactor, who gave you well-written free software, which you then made insecure with your own patches.
If you remove the roof of your car with a chainsaw and are inevitably injured later, is it the car manufacturer's fault they didn't offer that model as a convertible from the factory?
The better question is why are people still trying to assign blame all these years later? The IT world dodged a bullet but has moved on (and likely didn't learn from their mistakes as supply chain attacks are steadily increasing).
2 replies →