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

[Mathias Payer <mathias dot payer at nebelwelt dot net>]

On 12/23/2016 03:35 PM, Alan Modra wrote:
> 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.

At the linker level you likely don't know if the referenced symbol is RO
or not (as it could come from any object) -- only the runtime loader has
this knowledge and at that time it is too late as PIE uses relative
addressing inside the object.

There is both a potential optimization story and a security story to
this issue. When compiling with PIE, the compiler assumes a relative
local offset to these globals, when compiling with PIC, the compiler
goes through the GOT, trading off performance for flexibility.

If we store, at the compilation unit level (or at the LTO level), that a
symbol is local or not local, then it could be optimized or handled
correctly. This new information would have to be stored somewhere in the
ELF file at the level of individual objects.

> I'll note that current x86 gcc makes more use of .dynbss and copy
> relocs than older versions..

Yes, that's what we observed as well. So this problem will become more
prominent in the future. Especially when defenses like vtable
authentication or CFI will become more wide-spread, this will turn into
a security problem.

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

Agreed. But likely the broader changes would also allow some
optimization along the way. I guess if we can argue for both performance
and security improvements, then people would be more willing to go
through with the changes.


>> PS: The C++ example code inf figure 4(a) has a typo, the call to the method
>> b2 should probably be to b1.

Can you be more specific? I don't see a call to b2 in Fig. 4a

Thanks,
Mathias

Attachment: signature.asc
Description: OpenPGP digital signature