Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Alan Modra <amodra at gmail dot 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
relocation.

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.
> 
> 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.
> 

-- 
Alan Modra
Australia Development Lab, IBM