Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

On Wed, 2004-09-22 at 17:13, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Ciaran McCreesh wrote:
> | On Wed, 22 Sep 2004 11:54:55 -0400 John Richard Moser
> | <nigelenki@×××××××.net> wrote:
>
> [...]
>
> | Personally, I don't see the point in an ugly hack which occasionally
> | sort of protects you from badly written code...

This is the same attitude I'd expect from somebody that would write
vulnerable code in the first place !@#$%^&

> The option's there for
>
> wtf?  It's been around for what, 6 years almost?  Sure, C doesn't do
> bounds checking, so this is technically a hack; but it's a very planned
> out, structured hack with specific goals.  Compiler optimizations are
> more of a hack; they rearrange and change your code around to make it
> run faster.
>
> Your use of 'occasionally' is blatantly misleading.  Unless I'm
> misremembering this, CERT has been getting more and more reports of
> programs with buffer overflow based vulnerabilities each year.  I
> thought it was up to something like 2000-3000 per year nowadays.  Last I
> looked there were about 170 format string based vulnerabilities.  I'm
> sure there's other types, but aside from good old retarded design (i.e.
> automatically executing scripts from untrusted sources as root by
> default), I haven't heard of them.  IANASE.

Yes. Our security team has currently done 141 GLSA's this year alone. 
42 of which match the string overflow.

Only 1 of those does not play along with -fstack-protector that I'm
aware of and that's being worked on currently.



>
> Vulnerabilities are 'occasionally' found, but of the lot of them, a good
> chunk is protected from with this.  Not all, but a lot.  The overhead
> from this is very minimal; and the proposal was only to implement it in
> the most vulnerable places.  It's usually not obviously visible even if
> implemented system-wide; at least, not until somebody overflows
> something and it aborts instead of giving them a shell.

Perhaps even expanding the scope of your original posting to the point
where we have a blacklist(hall of shame) would be a good idea. 
Maybe something like if the security team has to do a GLSA on a package
that involves a memory overflow then said package gets fstack for the
duration of it's lifetime at gentoo as well?

>
> Have you read the paper Etoh and Yoda wrote on SSP?
> http://www.trl.ibm.com/projects/security/ssp/main.html  It's very
> enlightening.
>
> | anyone who really wants it, but we tend more towards a "turn most things
> | off unless the user asks for them" approach, hence the relatively low
> | number of things turned on in the default USE settings.
>

> Well then leave it turned off, but put a note about the availability of
> the feature in the comments above FEATURES= in make.conf.

With FEATURES="noautossp" the user would be free to disable it on their
own accord but being a responsible distribution to the users and the
computing world we would/should not.

>
> |
> | | Any comments?  Would this be more suitable as a USE or a FEATURES
> | | setting?
> |
> | FEATURES, not USE.
> |
>
> - --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD4DBQFBUesPhDd4aOud5P8RAt1OAJjySIXem4RXzdJ01iVAvyTfjw/XAJ4wW8Yc
> IgmuKFSm88Q2C/tOVEVzFQ==
> =5dfk
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer