[FFmpeg-devel] [PATCH]configure: Enable pie for toolchain=hardened.

[Michael Niedermayer]

On Fri, Oct 14, 2016 at 06:28:32PM +0200, Michael Niedermayer wrote:
> On Thu, Oct 13, 2016 at 12:56:56AM +0200, Andreas Cadhalpun wrote:
> > On 12.10.2016 23:44, Carl Eugen Hoyos wrote:
> > > 2016-10-12 19:04 GMT+02:00 Andreas Cadhalpun <andreas.cadhalpun at googlemail.com>:
> > >> On 04.10.2016 12:24, Carl Eugen Hoyos wrote:
> > >>> Sorry if I miss something but with this patch, the hardening_check
> > >>> script succeeds here both for x86_32 and x86_64 (static and shared).
> > >>
> > >> This script uses a very simplistic approach for testing position
> > >> independent executables.
> > >> I think it just does the equivalent of 'readelf -h $PROGRAM | grep Type'.
> > >> If the Type is EXEC, it's a normal executable, and if it is DYN, it
> > >> assumes it's compiled as PIE.
> > > 
> > >> However, that doesn't guarantee that the executable is actually position
> > >> independent, i.e. does not contain text relocations.
> > > 
> > > My understanding of PIE is (very) limited but I suspect text relocations
> > > and PIE do not exclude each other.
> > 
> > As I understand it the literal meaning of position independent code is
> > code without text relocations, because those are what makes the code
> > position dependent. So in this literal sense PIE and text relocations
> > exclude each other.
> > (The -fPIC/-fPIE flags tell the compiler to produce code without text
> > relocations.)
> > 
> > The additional complication for executables is that ASLR doesn't work for
> > normal executables, because they are always mapped to the same point in
> > address space. The basic idea of PIE is to build the executables actually
> > as shared libraries, so that they can benefit from ASLR just as normal
> > shared libraries.
> > (The '-pie' flag tells the linker to produce such an executable.)
> > 
> > However, such a '-pie' executable is not necessarily position independent
> > in the literal sense, i.e. might contain text relocations.
> > In that sense PIE and text relocations don't exclude each other.
> > 
> 
> > If you want both NX and ASLR security features for an executable it has
> > to be built with '-pie' and must not contain text relocations.
> 
> this should not be true
> the difference between text relocations and lack there off is that
> without text relocations a binary is loaded and written into memory
> with text relocations the binary is loaded the addresses for
> relocations updated and writen into memory.
> There is at a theoretical level no difference in required access rights
> write to memory is neccessary at the load stage, no execute is needed
> here and once done rights can be fliped over into execute without write
> This may very well not work out that way in gnu linux but thats a
> implementation problem then not a fundamental issue in NX+ASLR+TEXRELs
> That is unless iam missing something
> 
> also a simple test:
> gcc xtest.c -pie -m32 -o xtest
> int main() {
>     void *ref;
> asm (
>     "mov $main, %0"
>     :"=r"(ref)
> );
> printf("? %p\n", ref);
> //can we read it ?
> printf("R %d\n", *(int*)ref);
> //can we write it ?
> *(int*)ref = 123;
> 
> return 0;
> }
> 
> Executing this shows that the write is prevented and segfaults, the
> address is different on each run and we have a text relocation in it
> thats on a ancient ubuntu without special security patches that i
> remember

Heres an example for 64bit with ASLR+TEXREL+non writable code
gcc xtest.c -fPIE -pie  -o xtest

int main() {
    void *ref;
asm (
    "movabs $main, %0"
    :"=r"(ref)
);
printf("? %p\n", ref);
//can we read it ?
printf("R %d\n", *(int*)ref);
//can we write it ?
*(int*)ref = 123;
printf("W\n");

return 0;
}

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161014/b31dd15a/attachment.sig>