Robert Connolly wrote:
>On Tuesday 28 November 2006 13:55, Robert Baker wrote: > > >>No ssp will require the removal of the regex_ssp patch in the perl >>section of the book. >> >> > >I noticed the regex_ssp patch for Perl wasn't needed anymore. I think it has >something to do with the way SSP was modified when integrated in glibc-2.4 >and gcc-4.1, compared to IBM's version. > > Understood. > > >>My question is if we intend not to use ssp in the >>2.4 branch doesn't that compromise the level of security offered by this >>kind of system? I realize that adding features to GCC can introduce >>issues in and of itself, but stack smashing is one of the most common >>attacks used today... Obviously if the patch affects the stability of >>the system then we are not there yet. >> >> > >The glibc-2.4/2.5 SSP library is not compatable with the SSP patch for gcc-3.4 >from IBM. I didn't look into back porting gcc-4.1's ssp to gcc-3.4 because I >suspect it's not straight foreward. I also noticed no one else backported it >either, like Debian or Gentoo. An alternative is replacing glibc-2.4/2.5's >SSP library with the one used in glibc-2.3.6, but it makes me wonder why does >it break Perl's regex. And another alternative is to use IBM's SSP with >libssp.so (there are patches for this), but again makes me wonder why it >breaks Perl's regex. > >With all the Grsecurity/PaX options enabled in the kernel, the only exploit >not detected by Grsec, which is detected by SSP, is "return2libc". While this >is fairly serious I don't think its practical to add SSP to a gcc-3.4 >toolchain, for a release which is expected to be rock-solid. I've considered >the alternative of using gcc-4.1.1 without mudflap and fortify_source to get >SSP into the 2.4-branch, but gcc-4.1.1 can't build a linux-2.4 kernel, and >can't build gcc-2.95.3, without tons of patches which would destabilize >gcc-2.95.3. There are unfortunate compromises when making a stable release, >and I think this is one of them. > > Indeed there will be compromises, and after I sent this email I thought about the fact that Grsecurity is being used. I agree return2libc attacks are a seriouse matter, and we know there are many attackers who use them. However when ASLR is being used these attacks should be much more difficult. (Although not impossible.) I can't say as I am surprised that using gcc-4 w/ a 2.4 kernel doesn't work. Times change projects move on.. >I hope to make up for this by using sound code in the base system, audited by >the stricter gcc-4.1.1 (or even gcc-4.2) compiler warnings in unstable and >merge the differences to the stable packages. > > > >>I have been running thru what we have thus far. In pass 2 of gcc I found >>I had to use --with-dynamic-linker= just to get the linker tests to >>pass after a gcc install. >> >> > >I removed the specs_x86 patch all together. It only worked on i386, and it was >screwing up Binutils' tests because Binutils detects the default dynamic from >parsing 'gcc --help --verbose', which produces the ./configure command used >to build GCC (like from gcc -v), and 'ld-*.so' matches twice and makes a mess >of the '-dynamic-linker' option used in Binutils tests. Since that patch only >worked for i386 its just as well to use an Sed command to prepend /tools to >the dynamic linker name when building GCC, and this will work fine with >uClibc too (with xml conditions). I preferred that patch with the idea of >having read-only sources, but its not a big deal. > > > Does the removal of the specs file still require a --with-dyanamic-linker= switch? --- [This E-mail scanned for viruses courtesy of Netslyder, Inc.(http://www.netslyder.net)] -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
