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

▲

dwattttt 2 hours ago | parent | next [-]

> The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process

They also suggest an alternative to storing the function pointer, store the bit flags that decide which function to call. That restricts the call targets to only the legitimate ones intended.

▲

ajross 8 hours ago | parent | prev | next [-]

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.

▲

ordu 6 hours ago | parent | prev [-]

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

▲

IAmLiterallyAB 6 hours ago | parent [-]

Yes but at best their "solution" is equally secure, not any better.

▲

ordu 4 hours ago | parent | next [-]

They argue, and I tend to agree, that their solution is more secure.

1. It impiles some function pointers to be writable temporarily, not all of them.

2. It doesn't hide writable pointers from a cursory glance not familiar with IFUNC.

	▲	anarazel 3 hours ago \| parent [-]
		The GOT has to be initially writable regardless of ifunc, even with relro, to apply relocations.

▲

kstrauser 5 hours ago | parent | prev [-]

Would xz still have been able to alter opensshd without IFUNC?

	▲	rwmj 34 minutes ago \| parent [-]
		Yes, liblzma could have used multiple routes to take over sshd. Once you're running inside the process it's game over. The exact details, like how they used ifunc and an audit hook, are very interesting, but ultimately not that important.