Steve Bergman wrote: > On Mon, 2002-09-16 at 15:29, Ben Reser wrote: > >>On Mon, Sep 16, 2002 at 02:17:50PM -0500, Steve Bergman wrote: >> >>>So, am I just not seeing the negative side to this? Immunix apparently >>>does not have enough name recognition and influence to make it happen. >>>But Mandrake does. After seeing exploit after exploit list RedHat, >>>SuSE, Debian. etc. as having a root vulnerability but with Mandrake as >>>just a DOS, I'm sure all the other distros would follow suit. >> >>Performance and it's bound to cause some programs not to build right >>causing people problems who want to build programs from tarballs. > > I started to write that the performance impact is trivial. However, > reviewing the info on the immunix site (which I admittedly haven't done > in a while) I find that, depending on the nature of the app, the > performance impact can be significant. > > FormatGuard does require some (small percentage of) programs to be > modified to compile. StackGuard does not seem to have this problem, > except with (surprise!) the Linux kernel. (And yes, that is a pain.) > > > > >>But no there isn't a whole lot of issues with doing this from what I've >>seen. >> >>However it is no guarantee to prevent successful attacks. I seem to >>recall that there have been some ways to get around it in the past. >>They get fixed but then you have to recompile all the apps to take >>advantage of it. > > > I know of one instance of this in (I believe) StackGuard 1.20. > > >>Think of it as a bandaide. Sooner or later the bandaide won't stick any >>more. >> > > > Good example. BandAid's are not a miracle cure. However, they are > still a very good idea. ;-) > > -Steve > >
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. 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". Bye. Giuseppe.
