This patch introduces PT_GNU_HEAP segment header, which tells the kernel or dynamic linker whether the binary or library needs executable heap or not... Counter part to Jakub Jelinek's [PATCH] for PT_GNU_STACK http://sources.redhat.com/ml/binutils/2003-05/msg00741.html This patch will be posted to the binutils mailing list after we have tested -Wa,--[no]execheap, -Wl,-z,[no]execheap respectively.
Created attachment 23023 [details, diff] binutils-2.14.90.0.7-execheap-pt-gnu-heap.patch
Heads up.. dont add this patch quite yet. First we need to repair this goofup, then we could add the pt gnu heap patch. ------------------------------------------------------------- Do not add sections to a PT_GNU_STACK segment. * From: Nick Clifton <nickc at redhat dot com> * To: binutils at sources dot redhat dot com * Date: Thu, 11 Dec 2003 18:02:54 +0000 * Subject: Do not add sections to a PT_GNU_STACK segment. ------------------------------------------------------------- Hi Guys, I am applying the small patch below to add an extra test to the INCLUDE_SECTION_IN_SEGMENT macro in bfd/elf.c. This test prevents sections from being assigned to a PT_GNU_STACK segment, even if it would appear that it contains them. This proved to be a problem when stripping an executable containing a stack segment - it would have sections assigned to it, and suddenly its start address would change to coincide with the first matching section... Cheers Nick 2003-12-11 Nick Clifton <nickc@redhat.com> ------------------------------------------------------------- http://sources.redhat.com/ml/binutils/2003-12/msg00205.html A quick search of the gnu.stack permissions that my bins have been compiled with show me that pretty much every package thats been compiled recently got marked with as needing an executable stack "E". So this becomes an issue of security as well. # (scanelf comes from pax-utils) scanelf -l -p | awk '{print $3}' | while read f p ; do stack="`readelf -l $f | grep STACK`" ; [ $? == 0 ] && echo $f $stack | awk '{print $8,$2,$1}'; done | grep ^RWE returns pretty much every recently compiled gcc-3.3.2 bin on my system as needing an executable stack. # so our patch would look more or less like. + && segment->p_type != PT_GNU_STACK \ + && segment->p_type != PT_GNU_HEAP \
Did I mention this is a major security risk for those that have kernels that support can support PT_GNU_ flags?
Created attachment 23797 [details, diff] binutils-2.14.90.0.7-bfd-pt-gnu-segment-fix
Created attachment 23798 [details, diff] binutils-2.14.90.0.7-rX ebuild for all of this.
solar, a couple of things: 1. add yourself to base-system (or ask klieber to if the alias isn't in /var/mail/alias/misc on dev.g.o 2. With this patch set, how much testing has it seen on your boxes, boxes of other hardened people, and boxes of non-hardened people? If you can attach results from those three, this would see action quicker. If you think that toolchain needs a team to be on it, then join the team. Until then, it's Azarah's responsibility, and take it from me Azarah has a LOT on his plate, so things won't move on your schedule, they'll move on his. Basically, if you're willing to take a more pro-active role, things might move more to your liking.
I've actually aynchronized several .7 patches for binutils-2.14.90.0.8 and added these patches in. .8 includes PT_GNU_STACK, but needed PT_GNU_HEAP still. I've sent the .8 ebuild and patches to Azarah for approval before I committed it, but if he's really busy, I can go ahead and add it and mask it.
We might want to hold off on that one for a moment now. binutils .8 has the GNU_STACK segment fix it it . However we did get the GNU_HEAP patches into gentoo and tested in time for the .8 release Now from reading the source code to a patch that Jakub Jelinek either has committed or is waiting for approval looks like it will conflict with PT_GNU_HEAP. http://sources.redhat.com/ml/binutils/2004-01/msg00070.html That leaves us witch a few choices. 1) Don't add the heap patch to gentoo at all and just wait for for it to come in via upstream. 2) Add the patch and don't use 0x6474e552 for assignment. (would do no good as no kernel would support it) 3) Combine efforts across gentoo, binutils, pax, redhat for future of PT_GNU_ segments. 4) Close bug, disable kernel support for segments and forget about it.
Did anybody contact Jacub?
Err, make that Jakub, sorry =)
This bug should die. .8 of binutils fixes the PT_GNU_STACK segment getting mismarked. PT_GNU_HEAP support will be(or has been) overridden by PT_RELRO PaX will look for another way to plug into the toolchain that it has more control of. If < .8 is to remain the stable for some time then we only need to add Nick Cliftons patch to the existing binutils
In -r4 - you may close this if PT_GNU_HEAP will drop.
Thanks.
