Re: Networking Pearl Harbor in the Making

[Joseph S D Yao <jsdy () center osis gov>]

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.