FRESH

Hacker News

Home

GNU IFUNC is the real culprit behind CVE-2024-3094

126 points by foltik

by phire

6 subcomments

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.

by wahern

3 subcomments

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).

by somat

0 subcomment

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

by countWSS

2 subcomments

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.

by warmdarksea

1 subcomments

seeing LD_PRELOAD in the "less-exploitable alternatives to GNU IFUNC" section was kind of funny

by AshamedCaptain

1 subcomments

The entire argumentation here is ridiculous. There's a big jump from "IFUNC slightly undermines RELRO" to "IFUNC is the real culprit". You could have gotten all but the same effect spawning a thread from a plain init or C++ constructor. No one should think that any relro, r^x or aslr or anything like this is going to deter anyone who can literally control the contents of the libraries which are linked in. They could, literally, exec a copy of sshd with a patched config if necessary.
The title is just clickbait.

by bla3

1 subcomments

I love the recently added "In Response to Hacker News" section.

by esbranson

0 subcomment

IDK I do find it funny the linked project readme is dunking on this thread.
And I am again going to mention the book Linkers and Loaders by John R. Levine from 1999, I'm not sure if there's anything comparable to it. How else does anyone know anything about this stuff?

by kristjank

0 subcomment

I will still hold the decision to link the biggest possible target on every server against the biggest, most privileged daemon on every server, as not very smart indeed.

by Panzerschrek

1 subcomments

> 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?

by theteapot

0 subcomment

False dichotomy. There was a series of blatant process failures from Github maintainer through Debian package maintainers. IFUNC also bad.

by rurban

0 subcomment

Well, also Unicode identifiers, a C11 spec bug, nobody cares to fix. Still in C26, because "users expect Unicode stability", esp. it's bugs.

0 subcomment

by octoberfranklin

1 subcomments

Yes, that nefarious nation-state threat actor known as GNU IFUNC!
Curses, thwarted again!

by TacticalCoder

3 subcomments

[flagged]

by liamgm

0 subcomment

xz-tools should scrap and reimplemented the code to the safer one , current one have safety and performance issue.

by washingupliquid

2 subcomments

> 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.