Gentoo Linux PIE-SSP Documentation1. Introduction to Randomization and Stack Protection First of all, the PaX homepage has moved to http://pax.grsecurity.net, please update your bookmarks. While the goal of the PaX suite has remained the same ever since, preventing memory related security vulnerabilities, there has been major advancements in the progress of getting similar and coexisting kernel patches into the attention of the wide public. Even though linear stack smashing attacks, formatstring overflows and return to libc style attacks cannot be fully prevented or suppressed by effective randomization of the running executable, there seems to be a wide consent amongst information security experts and GNU/Linux distributions that it does help putting up another barrier (see chapter 3). The outstanding support and help from the Gentoo toolchain main developer and coordinator, Martin Schlemmer as well as Dr. Hiroaki Etoh and moid from the OpenBSD team with the closer integration of the SSP patch into the Gentoo toolchain and userland has proven the common goals and commitments between developers throughout the world striving for better support and acceptance of technology that provides a security oriented, high quality, automatic response to simple linear stack overflow attempts. The positive feedback generated by users who are enhanced by the grsecurity patch being included as a standard security measure in the native gentoo-sources leads us to uphold the support for grsecurity in this common practice kernel. While the hardened-sources has been abolished in favour of the ongoing concurrent development of fully supported MAC/ACL schemes in Gentoo Hardened, selinux-sources and grsec-sources can benefit from the thorough implementation of a true PIE (position independent executables) and SSP (stack smashing protector) environment via the incorporated PaX patch. Chris Pebenito holds up the high quality and standard of the selinux-sources while keeping in touch with the PaX developments and introducing randomization and userland features of PIE and SSP via PaX or correlating patches according to the requirements of the solutions needed by our partners. The hardened-sources are maintained by hardened team and is the ideal kernel to use with a hardened toolchain. 3. GNU C Compiler and the history of PIE support As described in the introduction, in the last year we have seen major advancements (and confusion) in the GNU upstream toolchain regarding the implementation of a system wide scenario for storing information about stack protection requirements and randomization of executables via PIE (position independent executables) support. When the first PaX randomization patches came out, a modification to the GNU C compiler specs file was needed to create so-called "shared executables". This means that these days the linker was told to explicitly link -fPIC (gcc function to force the creation of position independent code) compiled .o object files with a interp.o interpreter field pointing to "/lib/ld.so" from glibc on the intel platform, using a special custom formed crt1S.o which was able to set up the addresses of "_main", "_init" (recent glibc: "__libc_csu_init") and "_fini" (recent glibc: "__libc_csu_fini") in the "_start" function in a position independent manner. So basically a setup like in a shared library was used to set up the PIC (position independent code) addressing of the data and the code segments in the executable that needs to be started via the main() function. There has been a bug on nonintel arches regarding the setup of the PIC register (%r19 on parisc) for statically linked binaries. Since this bug has been fixed on all arches we can support, it is now also safe to create this library-like PIC setup for statically compiled binaries. When Ingo Molnar from Redhat started to introduce the execshield kernel patches, the developers at Redhat also wanted to make use of the "hot and new" randomization for binaries, so Jakub Jelinek invested a lot of time in the preparation of the toolchain (binutils, glibc, gcc) to introduce the -pie flag which generates these binaries with the correct interpreter and a glibc provided Scrt1.o. With Russell Coker involved in the Fedora distribution of Redhat, the future directions to an Execshield based selinux setup with -pie support from the toolchain are a visible example for the integration of security improvements in a full-scale commercial office and home user distribution. Russell Coker also seems to be interested in supporting selinux for Debian. However, the technical approach to support compatibility needs of applications (java apps, gcc heuristically sets executable stack for nested functions) over default security measures (as implemented in PaX kernels) may not suit environments with higher risk analysis and threat potential. 4. A proven gcc extension for linear stack overflow protection When the OpenBSD team discovered SSP as their favourite utility to limit the possibility of linear stack overflows, they also evaluated the stack smash handler functions and found out that the best way to introduce SSP into their toolchain was a modification of the dynamic linker for executables requiring that no standard libraries were included (boot loaders!) and giving all other dynamically linked applications the chance to retrieve the guard object and the necessary related functions via their standard C library. Thus, the dynamically linked executables and shared libraries protected via propolice were using one exact shared copy of the __guard reference and the needed functions for setup and smash handling in a single location. Statically linked executables will have their own copy of __guard and the functions to work properly. On the Linux platform, Dr. Etoh decided to put the __guard, the __guard_setup and the __stack_smash_handler into the libgcc of the gcc package. This led to problems with big packages like apache2 and mod_php4 producing false positives because the wrong local __guard copies in shared libraries and/or the main executable were used by different __stack_smash_handlers, this odd momentum has been resolved and isolated in gdb sessions by pipacs from the PaX team. Having moid from the OpenBSD team to help us mitigating this negative side effect of the GNU C compiler and working close together with Dr. Etoh from the IBM labs in japan gave us the chance to introduce the first glibc-based SSP setup for userland in GNU/Linux for Gentoo-Linux at all! ( PIE-SSP it works! ) 5. Position Independent Executables with Propolice support On a Gentoo system this is currently accomplished by merging gcc:
While a hardened gcc starts the transparent conversion of a system to position independence for your binaries via making use of gcc spec file handling. Once the gcc has been equipped with that new specs file, a package or a kernel building can only return to the conventional building behaviour when it feeds the correct CFLAGS and LDFLAGS to the build process. As an example lets try the rebuilding our chpax binary as a position independent executable. We can use the file(1) command to determine if we in fact we are building our executables as ET_EXEC or ET_DYN. The first example here we have chpax built as a ET_DYN and the second one is chpax not built as a standard ET_EXEC file.
The gcc package has been designed to easily revert back to a conventional building environment behaviour in case of problems. Users can restore the original gcc specs file behaviour at any time by calling the gcc-config utility on the commandline. gcc-config -l ; gcc-config Ebuilds that experience problems with the a hardened gcc automatic transparency can evaluate the existence of the hardened gcc package on the target system and use compatibility CFLAGS to restore the original gcc behaviour during the emerge. Lisa Marie Seelye says you need the same hgcc and gcc versions on all distcc host volunteer machines.
|
|
