bobb at netslyder.net
Tue Nov 28 14:00:58 PST 2006
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.
>>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
>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
[This E-mail scanned for viruses courtesy of Netslyder, Inc.(http://www.netslyder.net)]
More information about the hlfs-dev