| |||||||||||||
|
| |||||||||||||
Hardening Linux against buffer overflowsHardening Linux against buffer overflowsPosted May 8, 2003 16:01 UTC (Thu) by brouhaha (subscriber, #1698)Parent article: Hardening Linux against buffer overflows I've never understood Linus' attitude about this. It's like saying "putting a lock on the door of your house won't completely prevent burglary, so instead you should get the police to catch and lock up all the burglars." No single change anywhere can solve the problem, but it's hard to see a downside to kernel patches that can substantially reduce the effectiveness of a whole class of exploits.
(Log in to post comments)
Hardening Linux against buffer overflows Posted May 8, 2003 16:27 UTC (Thu) by smoogen (subscriber, #97) [Link] When I have run into similar stances, and asked for clarification it is that too many people get caught up that the lock on the door will protect them completely. [For a real world example look at the run of Duct-Tape and Plastic sheeting in various US cities... the realities are that they would help some people but for most are placebos.]To summarize, some of us know that it will help a bit when used with other software contraceptives... but the majority of computer users will think it is the end-all and be-all of security.
Hardening Linux against buffer overflows Posted May 8, 2003 20:22 UTC (Thu) by iabervon (subscriber, #722) [Link] Well, in this case it's a bit like saying, "Putting a lock on your front door won't prevent burglary, because you have an unlocked side door they'll use instead." The problem is that a stack buffer overflow can be exploited in a number of ways, and only the simplest requires an executable stack. On the other hand, the new patch prevents a number of other exploits by putting more of the program out of harm's way. So it's possible that Linus will like it better, assuming he can't come up with an attack which will still work on otherwise correct programs that have a buffer overflow.
|
|
||||||||||||