liblame0 executable stack

[John Moser]

Binary package hint: liblame0

After building liblame0:

bluefox@icebox:/tmp/x/lame-3.96.1$ scanelf -qeRt .
RWX --- --- ./frontend/mp3x
RWX --- --- ./frontend/mp3rtp
RWX --- --- ./frontend/lame
RWX --- --- TEXTREL ./debian/liblame0/usr/lib/libmp3lame.so.0.0.0
RWX --- --- ./debian/lame-extras/usr/bin/mp3rtp
RWX --- --- ./debian/lame-extras/usr/bin/mp3x
RWX --- --- ./debian/lame/usr/bin/lame
RWX --- --- TEXTREL ./libmp3lame/.libs/libmp3lame.so.0.0.0
!WX --- --- ./libmp3lame/i386/.libs/fft3dn.o
!WX --- --- ./libmp3lame/i386/.libs/cpu_feat.o
!WX --- --- ./libmp3lame/i386/.libs/choose_table.o

The fix for this, as in bug #49283 (relating to libflac7), is to append the following code to libmp3lame/i386/*.nas:

; PT_GNU_STACK so we don't get a +X stack
%ifidn __OUTPUT_FORMAT__,elf
section .note.GNU-stack noalloc noexec nowrite progbits
%endif

I looked around and didn't see any calls or jumps or branches into esp-anything so I'm pretty sure this is safe.

Somebody should submit a patch to upstream.

[John Moser (nigelenki)]

bluefox@icebox:/tmp/x/lame-3.96.1$ scanelf -qeRt .
 TEXTREL ./debian/liblame0/usr/lib/libmp3lame.so.0.0.0
 TEXTREL ./libmp3lame/.libs/libmp3lame.so.0.0.0

By the way, I have nfc how to fix .text relocations. Oh well, at least they don't need an executable stack.

[John Moser (nigelenki)]

Removing "--enable-nasm" from debian/rules to disable inline assembly seems to get rid of the textrels as well. This gets rid of assembly optimizations.

It is most likely that the assembly code is seen as fixed position and thus the library can't move around. TEXTRELs rewrite addresses in the code to move it around:

foo.so: Position independent
--> foo.so:0x000a0000-000a1000: 64KiB of code that has to execute at base 0x00c00000

foo.so loaded at 0x0a000000
mprotect() 0x000a0000-000a1000 RW
foo.so+0x000a0000-000a1000 addresses modified
mprotect() 0x000a0000-000a1000 RX

This is a minor annoyance as it prevents the full protection of PaX mprotect() restrictions and selinux {execstack,execheap,execmem,execmod} (particularly execmod) but is difficult to fix without just ditching the assembly code.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Thank you for your bug report. Do you still have this issue with the latest Ubuntu ?

[John Moser (nigelenki)]

Testing liblame0...

$ scanelf -eRt /usr/lib/libmp3lame.so.0
 TYPE STK/REL/PTL TEXTREL FILE
ET_DYN RWX --- RW- TEXTREL /usr/lib/libmp3lame.so.0

Yes. The Stack has read/write/execute. I can't find a patch in Gentoo
(they tend to have patches for all of this stuff).

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Ok thank you, maybe you could contact the developpers of lame at http://sourceforge.net/projects/lame and offer them your patch.

[Gabriel Bouvigne (bouvigne)]

Not totally sure, but I think that this was corrected in 3.97 (we had a similar problem on Windows with DEP)

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Ok I'm marking this as fix committed, feel free to reopen if it happens again when 3.97 will be available in repos.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Should be fixed in Gutsy.