>> Think of a ISP shell computer, It's being constantly attacked. Assume
>> stupid hackers who dont find anything orignal but do know enought to read
>> bugtrack and modify an existing exploit. You've got 2500 users
>> and a new exploit arrives on bugtrack at 6PM.
>
>And what if that new exploit overcomes the no-stack-exec stuff?
>
>You (and others) say that crackers are stupid, and can only copy other
>peoples exploits. That still means that there needs to be just _one_
>person who writes an exploit to get a root shell through portmap or
>something. At which point the no-stack-exec patch is completely and
>utterly useless.
>
>What do you do then? You're back to square one, and NOTHING you have done
>has helped you in the least.
>
>If instead of even counting on the no-stack-exec patch you would have
>tried to fix one or two applications, at least you'd have made progress.
>
>In short, my argument is not that the kernel should not try to make things
>secure for you. My argument is that no-stack-exec adds nada, zero, zilch,
>nothing in the form or real security. With one simple change to some
>exploit, you're suddenly wide open.
>
>No, you may not be open to old exploits if you have the no-stack-exec
>patch. But old and known stack exploits aren't the issue: those are easy
>to fix in user space anyway.
If you are not hacked by the newest toy, but someone else is, and their
system is used to smurf the ever-loving crap out of you, are you any better
off? If the person who is hacked is a first time linux user on a university
dorm connection, do they have any hope of fixing the newest toy before being
hacked, backdoored, used to sniff other machines, and used to flood other
networks?
For those of us who ARE smurfed on a regular basis, the war we are fighting
is on the scale of hundreds of hacked machines. When dealing with network
floods, we are only as strong as our weakest system. If you can stop even
ONE packet warrior's exploit from working, you're doing something good. Why
not use every weapon in our arsenal, instead of arguing over how someone may
break one of our protections in the future so why implement it.
-
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.altern.org/andrebalsa/doc/lkml-faq.html