This is the mail archive of the
mailing list for the binutils project.
Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)
- From: Alan Modra <amodra at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Mathias Payer <mathias dot payer at nebelwelt dot net>, binutils at sourceware dot org, 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: Sat, 24 Dec 2016 01:05:54 +1030
- 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: <firstname.lastname@example.org> <email@example.com>
On Fri, Dec 23, 2016 at 01:58:38PM +0100, Florian Weimer wrote:
> 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?
I think you could fix the problem with just a linker change. Add
another section like .dynbss (.dynrelro maybe) that is used for
variables copied into the executable from read-only sections in shared
libraries. Like other relro sections it could be made read-only after
I'll note that current x86 gcc makes more use of .dynbss and copy
relocs than older versions..
> 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.
> PS: The C++ example code inf figure 4(a) has a typo, the call to the method
> b2 should probably be to b1.
Australia Development Lab, IBM