2.4 branch

Robert Baker 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.
>  
>
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)]




More information about the hlfs-dev mailing list