Free software's not-so-eXZellent adventure

Posted Apr 3, 2024 12:03 UTC (Wed) by smurf (subscriber, #17840)
In reply to: Free software's not-so-eXZellent adventure by dezgeg
Parent article: Free software's not-so-eXZellent adventure

> perhaps ifunc resolvers are called in an earlier stage than .init functions, or something

They might well be, but that's irrelevant since once you have an adversarial foothold in some library or other, running as root, you can do pretty much anything anyway, ifunc or .init or hijacked symbol.

More to the point: using an ifunc in order to choose the best implementation is fairly standard for crypto or compression code, thus doesn't jump at you when you look at the library's metadata. On the other hand, .init is used to build static objects and similar stuff which a reasonably-coded multi-thread-capable library should have no business requiring. The fact that it's easier to get gdb to trace code in .init sections than in ifuncs might be relevant too.

Free software's not-so-eXZellent adventure

Posted Apr 3, 2024 12:44 UTC (Wed) by ms (subscriber, #41272) [Link] (2 responses)

> They might well be, but that's irrelevant since once you have an adversarial foothold in some library or other, running as root, you can do pretty much anything anyway, ifunc or .init or hijacked symbol.

(ignoring the "running as root" clause)

I think this is maybe getting to the nub of it: if you link with a library, are you implicitly trusting it, to the extent that you're willing for it to write all over "your" memory, including code?

It's possible that for some of us who are used to thinking in terms of microservices, containers, etc etc, it doesn't seem hard to imagine a world where the answer is "no, I'm not trusting it that far - it can have its own memory, just like it has its own namespace, and its own scopes, but it doesn't get to interfere with mine". To me, it seems pretty crazy that all these languages typically enforce lexical scoping rules, but apparently glibc, with a combination of ifuncs and audit hooks, allows complete violation of the compartmentalisation that lexical scoping creates.

For some of us who are (I'm guessing) more experienced C/C++/kernel devs, there's both tradition, and good reason as to why believing/hoping/pretending the trust isn't absolute, is misguided.

Free software's not-so-eXZellent adventure

Posted Apr 3, 2024 15:32 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

You don't even need to be thinking in terms of microservices etc; Apple's dynamic linker requires imported symbols to be annotated with the library that's expected to supply the symbol, and thus most of the time, when you link against a library, you're only bringing it in for its symbols. I don't know if it has an equivalent of IFUNC, nor when static constructors are run (when a library is loaded, or when you first access a symbol from the library - both would be fine within the letter of C++).

Free software's not-so-eXZellent adventure

Posted Apr 7, 2024 17:31 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> when static constructors are run (when a library is loaded, or when you first access a symbol from the library - both would be fine within the letter of C++).

They are run when a symbol from the *object* containing the static object resides is accessed.