To the person that said most modern clients are smart enough to change UID
before accepting user input, I have to ask, how many times have you had to
upgrade sendmail, bind, ftpd, popd, imapd, rstatd, rlockd, portmap, ....
because of buffer overflow exploits that keep popping up? And even for
example, if you run bind non-root, if they can clobber your name server files
and screw up name service, even that will suffice to raise major havoc.
Besides if they can get a shell as ANY UID that gives them an inside base from
which to advance their attack.
It's pretty clear to me that applications programmers will never
adequately secure their code; and it's beyond the scope of what I can do to
re-write every application I use or to be absolutely sure there are no buffer
overflow or other exploits.
If you can stop the script kiddies; that's about 99.99% of the problem
solved.
I've looked at Stack Guard, but unfortunately, it can be gotten around
fairly easily and I'm sure at best it would just result in a new generation of
exploit scripts AND it's only applicable to x86 presently (most of my equipment
is Sparc based). I'd use it if it worked on Sparc anyway, because it's another
layer to get around.
I don't see unexecutable stack as a 100% fix, but it's another layer that
the script kiddies would have to get around. The more the better. It's always
going to be more difficult to stop a determined real hacker that actually knows
what they're doing, there are just too many bugs in any complex OS that someone
can creatively find ways to exploit, but for every real hacker there are 10,000
script kiddies out there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/