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.cadhal...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel