This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Mathias Payer <mathias dot payer at nebelwelt dot net>, binutils at sourceware dot org
- Cc: libc-alpha at sourceware dot org, Xinyang Ge <xxg113 at cse dot psu dot edu>, Trent Jaeger <tjaeger at cse dot psu dot edu>
- Date: Fri, 23 Dec 2016 13:58:38 +0100
- Subject: Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)
- Authentication-results: sourceware.org; auth=none
- References: <ec97c532-6576-8eec-05b0-1c206293b1b0@nebelwelt.net>
On 12/23/2016 12:50 PM, Mathias Payer wrote:
We want to report a vulnerability that is common in binaries on most
Linux distributions where binaries with PIE break common security
assumptions (like read-only format strings or immutable vtables).
Thanks for sharing your research!
The mitigation is to (a) recompile packages with -fPIC instead of -fPIE
or to (b) update the ELF format/loader linker toolchain so that
permissions of individual symbols can be tracked throughout the lifetime
of code.
Does (b) really require changes to the ELF format?
An undefined symbol reference as such cannot be turned into a copy
relocation because it lacks size information, and the static linker
needs object sizes to lay out the section contents (and dynamic linker
needs the size to make the copy). I would expect that at the same time
the size is looked up in the static linker, the section information
could be determined as well.
The question is whether this is the semantics we want, or if we'd prefer
if the reference itself determines the section type, like it is already
the case with symbol visibility. Implementing that would need broader
changes.
Thanks,
Florian
PS: The C++ example code inf figure 4(a) has a typo, the call to the
method b2 should probably be to b1.