nigelenki at comcast
Sep 23, 2004, 10:27 AM
Views: 1418
Permalink
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thierry Carrez wrote:
| Small data analysis based on August/September GLSAs :
|
| 55 GLSAs
| 21 of which are buffer overflows (38%)
| 5 are buffer overflows affecting daemons (9%)
| 14 are buffer overflows affecting client software (25%)
| 2 can potentially affect both servers and clients (4%)
|
| So almost one third of our current vulnerabilities are buffer overflows
| affecting client software. These require the attacker to make you
| load/read/open a malicious document/image/playlist.
Yeah, mozilla/libpng vulns, etc.
| It's not because we
| haven't seen much viruses for Linux that we shouldn't worry about this
| attack vector.
They'll catch up when Linux takes over the market. I don't think we
should "cross that bridge when we come to it;" I think we should be
ready for it.
| Restricting ssp to daemons and +s programs is not very
| useful. A client-based vulnerability can be used together with a recent
| root escalation kernel vuln to compromise a machine completely. Weakest
| link.
|
Hey, if you want to protect client programs i.e. Mozilla, gftp,
gtk-gnutell, xchat. . . . . GO FOR IT. These aren't high-intensity
tasks; they eat about 1% of CPU time >99% of the time, and occasionally
spike to something like 50%, maybe touch 100% for about 10mS at a time.
~ Nobody's going to notice.
On this note though, if you follow the logic through, you wind up
protecting every lib too eventually; what about libpng and libjpeg vulns
that can be used to exploit generic apps (mozilla again, but this time
not moz's fault so protecting moz does nothing)? This is why I say to
suggest -fstack-protector in make.conf in the comments just above CFLAGS
as well.
Where do we find things that we just don't care about? gcc maybe; wtf
do you do to exploit a compiler? But glibc? Everything uses glibc, if
there's a vuln then everything is vulnerable. Libncurses, libpng, gif
libraries, all used by web browsers.
A safer (from a security point of view) venue may be to allow users to
add CFLAGS="-fstack-protector" and FEATURES="autonossp" (notice the
'no') to have things determined to not need SSP have it removed.
Selecting things to protect means you have to be active and aggressive
in finding those programs and libs which would be potential targets;
selecting things that just obviously shouldn't or wouldn't need
protection can be done passively, because it's not a security concern to
protect an app that doesn't need it (only an overhead or performance
concern, depending on app).
The 'autonossp' and 'autossp' venues can coexist; anything that gets ssp
with 'autossp' should not be stripped of it with 'autonossp'. It's up
to you to decide if you want to implement one or both, and which should
be focused on more in the case of both.
| --
| Koon
- --
gentoo-security [at] gentoo mailing list
- --
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
iD8DBQFBUweDhDd4aOud5P8RAoC0AJ9kqf/cBy8eXJCDeu11fDYqnUNt4ACeL6+Z
tkRwGUwkCUkaV7/fGUWUPbA=
=AUoQ
-----END PGP SIGNATURE-----
--
gentoo-security [at] gentoo mailing list
|
