[Bug dynamic-link/21718] New: mount noexec bypass via direct ld invocation and (ab)use of relocations onto bss

["fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 21718
           Summary: mount noexec bypass via direct ld invocation and
                    (ab)use of relocations onto bss
           Product: glibc
           Version: 2.26
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: jinoh.kang.kr at gmail dot com
                CC: fweimer at redhat dot com
  Target Milestone: ---
                CC: fweimer at redhat dot com
             Flags: security?

Created attachment 10246
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10246&action=edit
Specially crafted demo "exploit" program, ELF x86_64

I think I have found a potential security issue on the operating
system where an aware attacker could execute a specially crafted ELF
file in the normal user privilege via explicitly invoking the loader
even when the eXecute permission is missing in its file mode and/or
the `noexec' flag is set on the mountpoint containing the executable.

This issue has quite been a traditional one, with an older, similar
issue (only involving the direct ld invocation) having been patched at
the kernel level by denying mmap PROT_EXEC requests on non-executable
files with EPERM. What this issue differs from that is an extra layer
atop the binary involving relocations (preferably R_<arch>_COPY) on a
executable "BSS" segment which enables us to inject executable codes
without ever mmap'ing an executable page from the original executable
file.

Although I do not see any severe security issues as this cannot affect
`setuid' or existing executables that cannot be modified by the
attacker, I think it may be worth patching since it may help prevent
some obscure attacks on a few specific secure configurations, and
doing so would make it consistent with existing behavior of the
loader.

The attached `test-program' executable, crafted for demonstration,
uses the AMD64 architecture and can be invoked as-is or directly using
the loader in a form like `/lib64/ld-linux-x86-64.so.2 ./test-program'
. It contains a simple code which issues the execve() system call to
invoke a shell on the system.

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