Giuseppe Ghib� wrote:

> 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.
>
>
>
>
>
why not with a standard install have it use the guarded versioon, with 
the majority of new Mandrake users coming from a windows environment, 
they won't think there was a performance hit at all, since anything over 
a 1/100 rate will be faster than windows.
( just for a test I ran an image through a few functions in corel photo 
paint on my 233 mhz p2 laptop, same image, same functions in corel photo 
paint on my wife's 600 mhz p3 tower under windows.
there was no appreciable difference in the time to perform the 
functions. therefore the hit wouldn't really affect new users coming 
from windows. they are used to slower functionality.)
expert install give the option for it or not.

Jaqui



Reply via email to