Tuesday, 21 July 2009

dev-libs/nss - executable stack markings

Compilation of version 3.12.3 of the nss library (dev-libs/nss) on my amd64 box resulted with executable and writable stack markings - which from security point of view is better if avoided ;) It also did not make some other programs happy that depend on this library when running under PAX system.

The initial hint was this:

* QA Notice: The following files contain writable and executable sections
* Files with such sections will not work properly (or at all!) on some
* architectures/operating systems. A bug should be filed at
* http://bugs.gentoo.org/ to make sure the issue is fixed.
* For more information, see http://hardened.gentoo.org/gnu-stack.xml
* Please include the following list of files in your report:
* Note: Bugs should be filed for the respective maintainers
* of the package in question and not hardened@g.o.
* RWX --- --- usr/lib64/nss/libfreebl3.so.12


Which was confirmed below - just in case ;)

user@host ~ $ scanelf -qe /usr/lib64/nss/libfreebl3.so
RWX --- --- /usr/lib64/nss/libfreebl3.so


So when I attempted to run firefox I got a segmentation fault :( Good old strace investigation shown:

user@host ~ $ strace firefox
...
open("/usr/lib64/nss/libfreebl3.so", O_RDONLY) = 46
read(46, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20:\0\0\0\0\0\0@"..., 832) = 832
fstat(46, {st_mode=S_IFREG|0755, st_size=431928, ...}) = 0
mmap(NULL, 2544672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 46, 0) = 0x6f9ca2b61000
mprotect(0x6f9ca2bc9000, 2093056, PROT_NONE) = 0
mmap(0x6f9ca2dc8000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 46, 0x67000) = 0x6f9ca2dc8000
mmap(0x6f9ca2dcb000, 13344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x6f9ca2dcb000
mprotect(0x6f9cba22b000, 3460, PROT_READ|PROT_WRITE) = -1 EACCES (Permission denied)


Oppsie!
There was another hint to this riddle though: http://hardened.gentoo.org/gnu-stack.xml. It's a very good read, btw! First, the ebuild had to be compiled and ready for further investigation:

ebuild /usr/portage/dev-libs/nss/nss-3.12.3.ebuild clean unpack compile
cd /var/tmp/portage/dev-libs/nss-3.12.3/work/nss-3.12.3/


Now which file has to be patched?

host nss-3.12.3 # scanelf -qeR .
RWX --- --- ./work/nss-3.12.3/mozilla/security/dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/lib/libfreebl3.so
RWX --- --- ./work/nss-3.12.3/mozilla/security/dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/lib/libfreebl3.so.12
!WX --- --- ./work/nss-3.12.3/mozilla/security/nss/lib/freebl/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/intel-aes.o
RWX --- --- ./work/nss-3.12.3/mozilla/security/nss/lib/freebl/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/libfreebl3.so.12


Aha! The intel-aes.o does not have correct markings set. Time for a patch...The actual source file is here:

/var/tmp/portage/dev-libs/nss-3.12.3/work/nss-3.12.3/mozilla/security/nss/lib/freebl/intel-aes.s

as suggested in the guide, adding this at the very bottom of the file:

#if defined(__linux__) && defined(__ELF__)
.section .note.GNU-stack,"",%progbits
#endif


And recompilation time...so the correct order would be this:
ebuild /usr/portage/dev-libs/nss/nss-3.12.3.ebuild clean unpack
Now patch the intel-aes.s file and then:

ebuild /usr/portage/dev-libs/nss/nss-3.12.3.ebuild compile install qmerge

No QA error reported! Job done! The actual bug was reported here: http://bugs.gentoo.org/show_bug.cgi?id=266343
All in all - that was an easy fix! :) This is now fixed in nss-3.12.3-r1

No comments:

Post a Comment

Have your say: