| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
Thierry Carrez wrote: |
| 7 |
| Small data analysis based on August/September GLSAs : |
| 8 |
| |
| 9 |
| 55 GLSAs |
| 10 |
| 21 of which are buffer overflows (38%) |
| 11 |
| 5 are buffer overflows affecting daemons (9%) |
| 12 |
| 14 are buffer overflows affecting client software (25%) |
| 13 |
| 2 can potentially affect both servers and clients (4%) |
| 14 |
| |
| 15 |
| So almost one third of our current vulnerabilities are buffer overflows |
| 16 |
| affecting client software. These require the attacker to make you |
| 17 |
| load/read/open a malicious document/image/playlist. |
| 18 |
|
| 19 |
Yeah, mozilla/libpng vulns, etc. |
| 20 |
|
| 21 |
| It's not because we |
| 22 |
| haven't seen much viruses for Linux that we shouldn't worry about this |
| 23 |
| attack vector. |
| 24 |
|
| 25 |
They'll catch up when Linux takes over the market. I don't think we |
| 26 |
should "cross that bridge when we come to it;" I think we should be |
| 27 |
ready for it. |
| 28 |
|
| 29 |
| Restricting ssp to daemons and +s programs is not very |
| 30 |
| useful. A client-based vulnerability can be used together with a recent |
| 31 |
| root escalation kernel vuln to compromise a machine completely. Weakest |
| 32 |
| link. |
| 33 |
| |
| 34 |
|
| 35 |
Hey, if you want to protect client programs i.e. Mozilla, gftp, |
| 36 |
gtk-gnutell, xchat. . . . . GO FOR IT. These aren't high-intensity |
| 37 |
tasks; they eat about 1% of CPU time >99% of the time, and occasionally |
| 38 |
spike to something like 50%, maybe touch 100% for about 10mS at a time. |
| 39 |
~ Nobody's going to notice. |
| 40 |
|
| 41 |
On this note though, if you follow the logic through, you wind up |
| 42 |
protecting every lib too eventually; what about libpng and libjpeg vulns |
| 43 |
that can be used to exploit generic apps (mozilla again, but this time |
| 44 |
not moz's fault so protecting moz does nothing)? This is why I say to |
| 45 |
suggest -fstack-protector in make.conf in the comments just above CFLAGS |
| 46 |
as well. |
| 47 |
|
| 48 |
Where do we find things that we just don't care about? gcc maybe; wtf |
| 49 |
do you do to exploit a compiler? But glibc? Everything uses glibc, if |
| 50 |
there's a vuln then everything is vulnerable. Libncurses, libpng, gif |
| 51 |
libraries, all used by web browsers. |
| 52 |
|
| 53 |
A safer (from a security point of view) venue may be to allow users to |
| 54 |
add CFLAGS="-fstack-protector" and FEATURES="autonossp" (notice the |
| 55 |
'no') to have things determined to not need SSP have it removed. |
| 56 |
Selecting things to protect means you have to be active and aggressive |
| 57 |
in finding those programs and libs which would be potential targets; |
| 58 |
selecting things that just obviously shouldn't or wouldn't need |
| 59 |
protection can be done passively, because it's not a security concern to |
| 60 |
protect an app that doesn't need it (only an overhead or performance |
| 61 |
concern, depending on app). |
| 62 |
|
| 63 |
The 'autonossp' and 'autossp' venues can coexist; anything that gets ssp |
| 64 |
with 'autossp' should not be stripped of it with 'autonossp'. It's up |
| 65 |
to you to decide if you want to implement one or both, and which should |
| 66 |
be focused on more in the case of both. |
| 67 |
|
| 68 |
| -- |
| 69 |
| Koon |
| 70 |
|
| 71 |
- -- |
| 72 |
gentoo-security@g.o mailing list |
| 73 |
|
| 74 |
|
| 75 |
|
| 76 |
- -- |
| 77 |
All content of all messages exchanged herein are left in the |
| 78 |
Public Domain, unless otherwise explicitly stated. |
| 79 |
|
| 80 |
-----BEGIN PGP SIGNATURE----- |
| 81 |
Version: GnuPG v1.2.6 (GNU/Linux) |
| 82 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 83 |
|
| 84 |
iD8DBQFBUweDhDd4aOud5P8RAoC0AJ9kqf/cBy8eXJCDeu11fDYqnUNt4ACeL6+Z |
| 85 |
tkRwGUwkCUkaV7/fGUWUPbA= |
| 86 |
=AUoQ |
| 87 |
-----END PGP SIGNATURE----- |
| 88 |
|
| 89 |
-- |
| 90 |
gentoo-dev@g.o mailing list |
Archives