Re: Stack-smashing protection
On Fri, 2002-12-06 at 18:29, Albert Cervera Areny wrote: I've read in slashdot (http://bsd.slashdot.org/article.pl?sid=02/12/02/2035207) that openbsd has included stack-smashing protection using the ProPolice (http://www.trl.ibm.com/projects/security/ssp/) patch for GCC 3.2 I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. Would somebody make some kind of statistics of how many of this year's bugs wouldn't have made the system vulnerable with this patch? Though there is about of 8% performane overhead I think it is worth using this. And more now that gcc makes programs about 8% faster ;-) Hi, We are running more architectures than OpenBSD project with more and more packages.The overhead cost(8%) sounds good for me, but about the cost to rebuild the entire archive? And if i need one package without the protection? We will keep two archives? Debian can't, it's obviously a bad idea.But if anyone can rebuild the entire Woody for i386 with propolice, stackguard or anything like, good too! I guess that Debian can support one more kernel flavor, it's so easy.You can see the previous commented patch called grsecurity, it has PaX and more interesting features to enhance security without rebuild the entire system.Comments here? cya, Gustavo Franco -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stack-smashing protection
On Fri, 2002-12-06 at 18:29, Albert Cervera Areny wrote: I've read in slashdot (http://bsd.slashdot.org/article.pl?sid=02/12/02/2035207) that openbsd has included stack-smashing protection using the ProPolice (http://www.trl.ibm.com/projects/security/ssp/) patch for GCC 3.2 I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. Would somebody make some kind of statistics of how many of this year's bugs wouldn't have made the system vulnerable with this patch? Though there is about of 8% performane overhead I think it is worth using this. And more now that gcc makes programs about 8% faster ;-) Hi, We are running more architectures than OpenBSD project with more and more packages.The overhead cost(8%) sounds good for me, but about the cost to rebuild the entire archive? And if i need one package without the protection? We will keep two archives? Debian can't, it's obviously a bad idea.But if anyone can rebuild the entire Woody for i386 with propolice, stackguard or anything like, good too! I guess that Debian can support one more kernel flavor, it's so easy.You can see the previous commented patch called grsecurity, it has PaX and more interesting features to enhance security without rebuild the entire system.Comments here? cya, Gustavo Franco -- [EMAIL PROTECTED]
Re: Stack-smashing protection
On Mon, 9 Dec 2002, martin f krafft wrote: also sprach Albert Cervera Areny [EMAIL PROTECTED] [2002.12.06.2129 +0100]: I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. gcc is already the compiler by default ... and you can use stackguard to tighten gcc - better still, write better code ?? have a look at grsecurity.net, which i think implements this at a lower cost. and the rest of the dozen+ kernel hardening tools http://www.linux-sec.net/Harden/kernel.gwif.html c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stack-smashing protection
On Mon, 9 Dec 2002, martin f krafft wrote: also sprach Albert Cervera Areny [EMAIL PROTECTED] [2002.12.06.2129 +0100]: I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. gcc is already the compiler by default ... and you can use stackguard to tighten gcc - better still, write better code ?? have a look at grsecurity.net, which i think implements this at a lower cost. and the rest of the dozen+ kernel hardening tools http://www.linux-sec.net/Harden/kernel.gwif.html c ya alvin
Re: Stack-smashing protection
A Saturday 07 December 2002 2:37, David B Harris va escriure: On Sat, 7 Dec 2002 01:09:59 +0100 Albert Cervera Areny [EMAIL PROTECTED] wrote: So it isn't really that the hole system runs 8% slower. Sorry for my first explanation... Now I think it is an overhead which is afordable seeing its benefits. For your purposes, anyways. As has been said, this will likely never be a Debian-wide thing; I imagine that if anything there will be an option for it. Well... then I don't think It could be an option as It would require recompile almost every package again for each architecture and then I don't think it'd be possible :-( That was just an idea... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stack-smashing protection
A Saturday 07 December 2002 2:37, David B Harris va escriure: On Sat, 7 Dec 2002 01:09:59 +0100 Albert Cervera Areny [EMAIL PROTECTED] wrote: So it isn't really that the hole system runs 8% slower. Sorry for my first explanation... Now I think it is an overhead which is afordable seeing its benefits. For your purposes, anyways. As has been said, this will likely never be a Debian-wide thing; I imagine that if anything there will be an option for it. Well... then I don't think It could be an option as It would require recompile almost every package again for each architecture and then I don't think it'd be possible :-( That was just an idea...
Re: Stack-smashing protection
8% is a huge hit, by all means a module or an option, however I question its need as standard. I would not want it there unless Im convinced it truely offers protection from a quantifiable risk. I dont want to see the kernel go the way of MS's kernel ,one huge bloated mess. Lets see some papers/justification for this item, it may not be needed in all situations. regards Thing On Sat, 07 Dec 2002 09:29, Albert Cervera Areny wrote: I've read in slashdot (http://bsd.slashdot.org/article.pl?sid=02/12/02/2035207) that openbsd has included stack-smashing protection using the ProPolice (http://www.trl.ibm.com/projects/security/ssp/) patch for GCC 3.2 I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. Would somebody make some kind of statistics of how many of this year's bugs wouldn't have made the system vulnerable with this patch? Though there is about of 8% performane overhead I think it is worth using this. And more now that gcc makes programs about 8% faster ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stack-smashing protection
Sorry, I didn't say it as it really is... It shows an 8% overhead on function calls, which should be the upper bound on the real costs of running programs under this protection system. The overall overhead of guarded programs varies with how many functions are called that have character array. Figure 10 shows a program's name, its description, the number of functions declared, and the number of functions used with character arrays. In most cases, the usage of a character array is less than 10% of the functions. It isn't the same as the ratio of the number of functions executed, but there is a some correlation between them. Some overhead examples are in the web page (http://www.trl.ibm.com/projects/security/ssp/node5.html#SECTION00051000; quite a nice URL ;-) Perl 4% ctags 1% impad 0% So it isn't really that the hole system runs 8% slower. Sorry for my first explanation... Now I think it is an overhead which is afordable seeing its benefits. A Friday 06 December 2002 23:13, Thing va escriure: 8% is a huge hit, by all means a module or an option, however I question its need as standard. I would not want it there unless Im convinced it truely offers protection from a quantifiable risk. I dont want to see the kernel go the way of MS's kernel ,one huge bloated mess. Lets see some papers/justification for this item, it may not be needed in all situations. regards Thing On Sat, 07 Dec 2002 09:29, Albert Cervera Areny wrote: I've read in slashdot (http://bsd.slashdot.org/article.pl?sid=02/12/02/2035207) that openbsd has included stack-smashing protection using the ProPolice (http://www.trl.ibm.com/projects/security/ssp/) patch for GCC 3.2 I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. Would somebody make some kind of statistics of how many of this year's bugs wouldn't have made the system vulnerable with this patch? Though there is about of 8% performane overhead I think it is worth using this. And more now that gcc makes programs about 8% faster ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stack-smashing protection
8% is a huge hit, by all means a module or an option, however I question its need as standard. I would not want it there unless Im convinced it truely offers protection from a quantifiable risk. I dont want to see the kernel go the way of MS's kernel ,one huge bloated mess. Lets see some papers/justification for this item, it may not be needed in all situations. regards Thing On Sat, 07 Dec 2002 09:29, Albert Cervera Areny wrote: I've read in slashdot (http://bsd.slashdot.org/article.pl?sid=02/12/02/2035207) that openbsd has included stack-smashing protection using the ProPolice (http://www.trl.ibm.com/projects/security/ssp/) patch for GCC 3.2 I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. Would somebody make some kind of statistics of how many of this year's bugs wouldn't have made the system vulnerable with this patch? Though there is about of 8% performane overhead I think it is worth using this. And more now that gcc makes programs about 8% faster ;-)
Re: Stack-smashing protection
Sorry, I didn't say it as it really is... It shows an 8% overhead on function calls, which should be the upper bound on the real costs of running programs under this protection system. The overall overhead of guarded programs varies with how many functions are called that have character array. Figure 10 shows a program's name, its description, the number of functions declared, and the number of functions used with character arrays. In most cases, the usage of a character array is less than 10% of the functions. It isn't the same as the ratio of the number of functions executed, but there is a some correlation between them. Some overhead examples are in the web page (http://www.trl.ibm.com/projects/security/ssp/node5.html#SECTION00051000; quite a nice URL ;-) Perl 4% ctags 1% impad 0% So it isn't really that the hole system runs 8% slower. Sorry for my first explanation... Now I think it is an overhead which is afordable seeing its benefits. A Friday 06 December 2002 23:13, Thing va escriure: 8% is a huge hit, by all means a module or an option, however I question its need as standard. I would not want it there unless Im convinced it truely offers protection from a quantifiable risk. I dont want to see the kernel go the way of MS's kernel ,one huge bloated mess. Lets see some papers/justification for this item, it may not be needed in all situations. regards Thing On Sat, 07 Dec 2002 09:29, Albert Cervera Areny wrote: I've read in slashdot (http://bsd.slashdot.org/article.pl?sid=02/12/02/2035207) that openbsd has included stack-smashing protection using the ProPolice (http://www.trl.ibm.com/projects/security/ssp/) patch for GCC 3.2 I think it would be a great idea to use this patch with debian too as soon as gcc becomes the compiler by default. Protecting the entire system from this kind of bugs would really be a great security step forward. Would somebody make some kind of statistics of how many of this year's bugs wouldn't have made the system vulnerable with this patch? Though there is about of 8% performane overhead I think it is worth using this. And more now that gcc makes programs about 8% faster ;-)
