Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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.




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.