[Bug dynamic-link/31594] New: IFUNC relocation resolving should constrain resolver and result

[Bug dynamic-link/31594] New: IFUNC relocation resolving should constrain resolver and result

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31594

            Bug ID: 31594
           Summary: IFUNC relocation resolving should constrain resolver
                    and result
           Product: glibc
           Version: 2.29
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For security reasons both the resolver and the resolver result should point
inside the IFUNCs dynamic object.  Ideally the resolver should already have
bound locally (but I don't think this is technically required but by the
undefined order of relocating it).  Ideally the result would not require
further relocation (thus should not be the address of a PLT) but again
that's not enforced.  Having PLT addresses as result might complicate the
implementation of the check.  Possibly the link editor can offer diangostics
to sanitize IFUNC users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/31594] IFUNC relocation resolving should constrain resolver and result

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31594

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
The resolver has to come from the symbol's object due to the way the address of
the resolver is encoded in ELF. A restriction on the address returned from the
resolver would prevent legitimate redirection to another shared object. (There
is some ambiguity whether IFUNC resolvers can refer to external symbols.)

I don't see how this is a security-related change. The IFUNC resolver code is
trusted with and without this change. A malicious IFUNC resolver can just
return the address of a trampoline in the current object to satisfy any address
check.

-- 
You are receiving this mail because:
You are on the CC list for the bug.