This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: dynrelro section for read-only dynamic symbols copied into executable
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Tue, 27 Dec 2016 20:55:33 -0800
- Subject: Re: dynrelro section for read-only dynamic symbols copied into executable
- Authentication-results: sourceware.org; auth=none
- References: <20161226054448.GC340@bubble.grove.modra.org>
> Variables defined in shared libraries are copied into an executable's
> .bss section when code in the executable is non-PIC and thus would
> require dynamic text relocations to access the variable directly in
> the shared library. Recent x86 toolchains also copy variables into
> the executable to gain a small speed improvement.
>
> The problem is that if the variable was originally read-only, the copy
> in .bss is writable, potentially opening a security hole. This patch
> cures that problem by putting the copy in a section that becomes
> read-only after ld.so relocation, provided -z relro is in force.
It doesn't look like you caught the case where the original variable
is in the .data.rel.ro section (which is marked SHF_WRITE initially,
but placed in the PT_GNU_RELRO segment). These variables should also
be copied to .data.rel.ro in the main executable.
I've just committed a gold patch for this. To identify relro
variables, I checked the section name (ugly) -- I considered checking
the virtual address against the bounds of PT_GNU_RELRO, but that
wasn't really efficient.
I wish we had an SHF_RELRO flag.
-cary