North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Networking Pearl Harbor in the Making
On Mon, Nov 07, 2005 at 02:43:54PM -0600, Robert Bonomi wrote: ... > Most exploits (be it IOS or some other target) require multiple things to occur > before the "desired effect" is achieved. > > "buffer overflow" exploits. in general. involve a minimum of two things: > 1) "smashing" memory outside of the area you 'should' have been limited > to. > 2) having 'some other code' accept/use that 'improperly modified' memory > believing it to be 'valid' content. > > Causing =any= step of the exploit process to fail means that the attempt > _does_not_succeed_. > > Re-coding to eliminate all 'possible' buffer overflow situations is a *big* > job. The required field-length checking for every multi-byte copy/move > operation does have a significant negative impact on performance, as well. > > Merely _identifying_ the 'tainted' (by being in contact -- directly or in- > directly -- with 'user-supplied' data) data-structures is a task measured > in man-years. As is isolating _all_ the points where such tainting occurs. > Then, and only then, can you begin to -plan- how to remove the taint, whether > by sanity-based bounds-checking, 'clipping' to known limits, explicit length > checks, or whatever else is appropriate. > > *AFTER* all that, you can =start= implementing the code that removes taint. > > It _can_ be much quicker (in terms of "time to delivery to the field") to > go after one of the 'other things' that has to happen for an exploit to > "work". There actually is automated code to identify and correct stack overflows on Linux. Formerly StackGuard, then Immunix, it looks like it's now Novell AppArmor (*shudder*). -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
|