Bug#528080: ffmpeg-debian: ffmpeg still has shlib-with-non-pic-code lintian errors

[Andreas Cadhalpun]

On 16.10.2016 13:31, Niels Thykier wrote:
> Andreas Cadhalpun:
>> By the way, do you happen to know what problems these text relocations
>> cause from a security point of view?
>> (I thought they were incompatible with NX, but that seems not to be
>> the case [1].)
> 
> I wish I did.  For an executable, the absence if PIE makes the linker
> load the binary at a fixed offset, making it very easy to determine
> (some) addresses for ROP attacks.

Yes, PIE makes ASLR useful for executables.

>   AFAICT, for non-PIC shared-libraries the linker still has to relocate
> it, but I cannot quite figure out if that method is easier to exploit or
> not.
> 
> I suspect you might be derive it from reading the following two articles[1]:
> 
>  *
> http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/
>  *
> http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
> 
> 
> ~Niels
> 
> [1] The PIC one mentions "lazy binding optimization" as an
> (optimization) advantage.  As I recall, that feature is effectively
> negated when using the "relro" (default) and the "bindnow" (suggested as
> a default) hardening flags.

That's correct. It also says:
"Moving relocations from the code section, however, allows to make it read-only
 and share it between processes."

I've seen similar statements elsewhere on the web, however, Michael's example
shows that even with text relocations, the text section is read-only when the
program runs.

So the remaining advantage is that the text section of PIC shared libraries
can be shared between processes, which is nice, but IMHO faster decoding
speed is even nicer. ;)

Best regards,
Andreas