North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Networking Pearl Harbor in the Making

  • From: Joseph S D Yao
  • Date: Mon Nov 07 16:13:11 2005

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.