[86503] in North American Network Operators' Group
Re: Networking Pearl Harbor in the Making
daemon@ATHENA.MIT.EDU (Joseph S D Yao)
Mon Nov 7 16:12:37 2005
Date: Mon, 7 Nov 2005 16:12:11 -0500
From: Joseph S D Yao <jsdy@center.osis.gov>
To: Robert Bonomi <bonomi@mail.r-bonomi.com>
Cc: nanog@merit.edu
Mail-Followup-To: Robert Bonomi <bonomi@mail.r-bonomi.com>,
nanog@merit.edu
In-Reply-To: <200511072043.jA7Khs9u004513@host122.r-bonomi.com>
Errors-To: owner-nanog@merit.edu
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.
