On Tue, Sep 17, 2002 at 11:19:10PM +0200, Giuseppe Ghib� wrote: > IMHO point everytime out that more or less boundary checking techniques > would > have impact on performance is annoying. MHHO is this: "the program compiled > with > boundary checking enabled is slow(er) by a factor of 10 (and even 100)? I > would > answer "and then? buy a faster machine if you need more power and want to > use > boundary protected programs". Seems that the only importance > is performance, while most the the vulnarable machines are machine > with low traffic, whose daemons are doing almost anything, where the > administrator maybe doesn't exists, or doesn't have the time to apply new > RPM > updates on a daily basis. Such machines are mostly vulnerable to new worms > which > often appears on a standard basis after the advisors. In such cases, for > instance, an apache server running at a factor speed of 1/100 with respect > to > the unprotected version is insignificant.
Even with an insignificant performance problem (which is debatable). It would have little purpose. As an admin a tool like this wouldn't give me better sleep. As I've pointed out before there have been ways found around such tools. The only better sleep I get is by verifying that I am patched against the vulnerability with a real fix. As far as worms go there have been realtively few Linux worms. And all of them have been for well known and already patched issues. Something like StackGuard provides an insignificant amount of added protection for people who apply the proper updates. As such I think the hassle of it is just isn't worth it. And it's not just perforance... > Certainly SG (like other tools, e.g. libsafe) it's not a panacea against > every > attack and should NEVER be considered a replacement for standard timely > updates, > but could save the sleep of many administrators to the next morning (like a > spare wheel), who maybe don't remember if they are vulnerable or not to the > latest worm...; now not considering that the StackGuard 2.0 patch is only > available for obsolete compilers (we are currently at gcc 3.2, while > stackguard > is still for egcs 1.1.2) and that is two years that isn't upgraded, but a > way > would be NOT to compile the entire distro with stackguard, kernel included, > but only the most common network daemons and the libraries they use, then > link > these programs statically with a stackguarded compiled version of glibc. For > instance openssh and openssl, apache, php, perl, sendmail/postfix, bind, > cups > [not telnet, nfs, portmap, because there shouldn't be anyway ;-)], > anonymousftp, > etc.; furthermore these packages should be installed on demand as > "alternative" > to standard (unstackguarded) ones, not as mandatory and unique > "replacement". This would create new problems... If you start compiling the things you are talking about with the stackguard compiler you're going to end up with one heck of a lot of stuff compiled with it. I'd have to sit down and look at the depencies but I think you might very well run into incompatiblities in C++ mangling. Granted that most of these apps are in C not C++, but perl is used by lots of things as an interpretor and if just one of those is written in C++ you have a headache on your hands. I just don't think it's worth it. If it was then all the distros would already be doing it and the Immunix patches would have been merged into the mainline gcc. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
