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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
