This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/21718] New: mount noexec bypass via direct ld invocation and (ab)use of relocations onto bss
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 07 Jul 2017 11:10:01 +0000
- Subject: [Bug dynamic-link/21718] New: mount noexec bypass via direct ld invocation and (ab)use of relocations onto bss
- Auto-submitted: auto-generated
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.