Re: DoS is an attack

Post #32,282 by wharris2 3/15/02 12:08:18 AM Reply	Re: DoS is an attack For instance a double-free at point A will lead to point B starting to execute code from point C, where C holds a user-defined text string. Right. When these alarmists can give an example of an actual exploitation, I'll believe it. This alarm involves a known problem that could involve a hypothetical problem that might somehow let another hypothetical exploit theoretically invoke a buffer overflow that might possibly have a problem. It may be a security problem, but I see it as a FAR less problem than most of the hundred other Microsoft problems. It's not a maximum "red alert" piss-your-pants problem that it's been portrayed as. Where each demon is slain, more hate is raised, yet hate unchecked also multiplies. - L. E. Modesitt
Post #32,316 by Yendor 3/15/02 9:56:32 AM Reply	Then I suggest... ...that you simply not upgrade any of your systems that might be affected. Wait until someone can figure out how to exploit it. And then you can attempt to maybe possibly use your machine as an after-the-fact honeypot. Meanwhile, I'll just go run red-carpet, update my system, and not worry about it. -YendorMike Real programmers use "vi a.out".
Post #32,434 by wharris2 3/16/02 10:05:44 AM Reply	I've run into double-free problems before The memory arena is corrupted, and eventually the program core dumps. I can't get my mind around a way to reliably exploit it. Getting the condition to happen and somehow using it for a denial of service attack, I can see how that might be possible, but it's not worth worrying about for a home system. Where each demon is slain, more hate is raised, yet hate unchecked also multiplies. - L. E. Modesitt
Post #32,361 by kmself 3/15/02 2:12:46 PM Reply	It's a known class of exploit... ...touching a large number of programs and systems. Buffer overflows are a very common class of root causes for security exploits. Testing for, and avoiding, overflows is a (relatively) simple, prophilactic measure that can avoid many, many possible exploits. [link\|http://www.openbsd.org/\|OpenBSD] uses modified C libraries to do just this. Proprietary products (IIRC, StackGuard is one) work similarly. I also believe that one of the ideas behind Java is to protect writeabe (and readable) memory. One of the classic explorations of comparative robustness of free software vs. proprietary software is [link\|http://online.securityfocus.com/library/2087\|Fuzz Revisited], uses the relatively simple test of throwing arbitrary junk input to a program and watching the results. I suggest again looking at my "Risks" comment above. `-- Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com] [link\|http://kmself.ix.netcom.com/\|[link\|http://kmself.ix.netcom.com/\|http://kmself.ix.netcom.com/]] What part of "gestalt" don't you understand?`

Welcome to IWETHEY!