Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jason Wever wrote:
| On Sat, 25 Sep 2004 19:26:26 +0200
| Bart Lauwers <blauwers@g.o> wrote:
|
|

[...]

|>2) The risk is real and errors against this seem common.
|
|
| Sure, there is risk in almost everything too.  However just because
| driving an automobile can be dangerous doesn't mean I'll buy a tank or
| stay inside just to feel safe.

No, but you'll get one with strong bars in the doors so taht side
impacts don't crush you to death, but rather push your car (crack open a
fiberglass car door once, you'll see 'em).  Also, rollbars on cars with
no hard-top, etc.

[...]


|
|
| Doesn't this exist already?  if people didn't trust Gentoo then why are
| they using it?  We can't be held ultimately responsible for software we
| didn't write.  If you can knock over service foo-1.2.3 on Gentoo, chances
| are you can knock it over on another Linux or possibly any other platform
| it runs on either.

I trust Gentoo in the security sense as much as I trust Mandrake, or
Debian, or SuSE.  The difference is that after taking notice of the
hardened project, I learned about all kinds of neat stuff like
- -fstack-protector and PaX, and now don't really trust anything else.

You can't be held responsible for others' security holes, but you can
take simple steps to mitigate the damages.

|
|

[...]

|
|
|>What I propose to do (pick the low hanging fruit):
|>1) Add stack protector and and any similar 'features' stable in hardened
|>to the default CLFAGS of the gentoo install/profiles. By stable I mean
|>things which do not break the majority of functionality.
|
|
| Feel free to take on the ownership of making this work on every arch's
| toolchain then.  Also feel free to deal with all upstream authors who
| start instantly dismissing any bugs from Gentoo due to the fact that the
| toolchain is quite modified to accomplish this task.  Take the current
| stance the GAIM team has with us as an example of what would be to come.

SSP works on all architectures.

As for upstream authors, guess what?


usr/lib/python2.3/site-packages/mx/TextTools/Examples/pytag.py:47:
SyntaxWarning: name 'debugging' is used prior to global declaration

python: stack smashing attack in function symtable_node()

error: command '/usr/bin/python' terminated by signal 6


Well SHIT!  Looks like I've got some MEANINGFUL information about a bug!
~ I mean damn, I can tell you right in what function the CHARACTER ARRAY
that got overflowed was created, and that it was created on the stack
(char a[n]); this leads you of course to the fact that it had to be
overflowed by some function that got called from this function AND
passed a character array, or somewhere along the line where that
character array was passed.

This is much more useful than "OMFG PYTHON R CRASH N STUFF WHEN I DO
STFUF!!!1@!2151!"

|
|
|>2) broken ebuilds can filter-flags until fixed (better approach since
|>you are only fixing up ebuilds for broken stuff and may also prompt the
|>devs to try and make the protection work).
|
|
| The protection itself is a work-around to the original problem.  You want
| to continue to work around the problem even more?
|

SSP is a work-around for buffer overflows that may or may not lead to
security exploits.

Filtering in ebuilds is a work-around for bad software which gets killed
because it's self-overflowing; or for software that triggers potential
bugs in SSP (yes, SSP is software, written by humans, geniouses yes but
humans, and can have bugs).  In the first case, of course, SSP tells you
almost exactly where to start looking.

|
|>3) People who prefer not to be protected can remove the settings from
|>their CFLAGS
|
|
| Personally, I don't think opting out is the way to do this.  Having CFLAGS
| that are in by default that may or may not work across all architectures
| is not a good thing.

Opting out of a feature which in usage you're normally not going to
really notice is there is no the way to do things?  Dude, that's like
saying you should make locks on windows optional.  They can be unlocked.

And ssp is supposed to be portable.  Etoh and Yoda's paper[1] says that
The IBM stack smash protection method (ProPolice) is CPU and OS
independent[2].  I think that you'd be within reason to complain to them
if it didn't work accross all archs.

[1] http://www.trl.ibm.com/projects/security/ssp/main.html
[2]
http://www.trl.ibm.com/projects/security/ssp/node4.html#SECTION00045000000000000000

|
|
|>4) get stuff virus, spam, etc protection functional and leveraged into
|>the defaults in other words turn on those USE flags in the standard
|>profiles
|
|
| No thanks.  I don't want to have to spend the first 24 hours or so of
| using my new"trusted" operating system opting out of all of the overly
| paranoid defaults.  If I'm looking for a high level of security out of the
| box, I'll use hardened or OpenBSD.
|
|
|>A personal opinion:
|>Anyone who thinks that a speed tradeoff is too much for better
|>protection is crazy. Do us all a favor and play a go night of russian
|>roulette by yourself to get your thrills.
|

1.  Within reason
2.  It has to actually affect speed.  Overhead != speed

|
| OK seriously, this kind of comment isn't needed.  I'm not sure what you
| hoped to have accomplished by it, but I'm fairly sure it didn't work.
|
| As anyone who has spent 5 minutes in the security world knows, there's a
| fine line between good security and paranoia.  You can lock your system
| down to high heaven and be sure that people won't get into it, but then
| you won't be able to do a damn thing either.  What good is that?
|

Yes, exactly.  -fstack-protector is one of those things you put there
and never notice, but it does its job.

| Right now I have a choice to use these features if I want to.  I don't
| have to "opt-out" and I would rather keep it that way.  The support
| nightmare this will create is not worth the potential advantages.

Yes and about 99.9999999% of your user base is probably going to say
"wha?  SSP?  Wassat?" if you ask them if they use SSP.

|
|
|>There's more to be said on security but I feel too lazy right now to
|>type it so if this isn't convinving you let us know.
|
|
| And as this list has shown historically, we can all argue security to high
| heaven with each party feeling they have the right answer and never
| accomplish anything.
|
| Now please don't get me wrong.  As someone who's day job is in the
| security field, I very much like and appreciate the efforts that have gone
| into making secure toolchains and hardened systems a reality in Gentoo.
| In some cases I do use them as well.
|

As someone who is passively absorbing this information, I find your
ignorance combined with your claim of being a security expert to
indicate that you're full of shit.

You've repetedly referred to the issue of cross-platform portability
with SSP in here, for example; and I've pointed out once a link that
shows that SSP is OS and CPU independent.  Do your research, read what's
out there.

I also pointed out how SSP helps you find AND fix the problems, where
you just said it's a work-around and that upstream maintainers will use
it as an excuse to fix bugs.  Instead of whining to them that shit
breaks and that they need to now find some way to reproduce the problem
OR just go audit their entire codebase over and over until they find it,
we can tell them EXACTLY where to start looking.  We can ALMOST tell
them where the bug is.  Doesn't this make life easier for all of us?

This tells me you haven't done your research, haven't tested the system
and triggered it intentionally to see what happens, have only a rough
idea if any what you're dealing with, and thus have no place commenting.

I'm no security expert, I don't claim to be; but I at least know the
subjet matter here better than you, for some strange and unknown reason.

| However, I do not believe it is our place nor our job to make that choice
| for our users.  You cannot protect people from themselves, regardless of
| the perceived benefits.
|

I can say that faster.  "General security is a lost cause; only security
experts have any business having security, even if it's transparent to
them."

| Regards,

- --
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

iD8DBQFBVl5KhDd4aOud5P8RArPxAKCPd1Y8uX9MH6UyVTSIsWGrwEedvwCeOecc
ewEb0aO0NZngjEfn5aOJ6eA=
=1ZJd
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list