On Mon, Apr 01, 2024 at 01:36:48PM -0400, Peter Jones wrote: > Unrelated to the idea that some packages are special in this way, it's > probably worth writing some static analysis tools we could put into > rpm-inspect to detect when (a) a binary grows new public keys it didn't > have before, and (b) a shared object grows a new ifunc. The latter is > dramatically easier, of course, but both of those should be pretty rare > events, so they're worth further inspection. I don't see much difference between ifuncs and any other library constructors from the exploit POV, at least with DT_BIND_NOW both is just some extra code run during library initialization. Sure, ifunc handlers affect what ifunc target is later called whenever calling the ifunc function, but harm can be done already when loading the library or the library constructor could overwrite function pointers, vtable pointers or just some data in the library to change its behavior later. So, in addition to watching for new ifuncs (and more importantly, trying to figure out if it is possible to statically prove the set of possible functions it will resolve to and compare to the old set; and if it isn't possible to statically figure out list of possible targets flag it for more careful inspection) we should watch for additions of __attribute__((constructor)) code or C++ namespace scope non-trivial ctors or dynamic initializers of namespace scope variables. Jakub -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
