[86606] in North American Network Operators' Group
Re: Networking Pearl Harbor in the Making
daemon@ATHENA.MIT.EDU (Robert Bonomi)
Fri Nov 11 12:04:41 2005
Date: Fri, 11 Nov 2005 11:03:44 -0600 (CST)
From: Robert Bonomi <bonomi@mail.r-bonomi.com>
To: nanog@merit.edu
Errors-To: owner-nanog@merit.edu
> Date: Fri, 11 Nov 2005 14:15:40 +0000 (GMT)
> From: "Edward B. Dreger" <eddy+public+spam@noc.everquick.net>
> Subject: Re: Networking Pearl Harbor in the Making
>
> RB> Date: Mon, 7 Nov 2005 14:43:54 -0600 (CST)
> RB> From: Robert Bonomi
>
> RB> Re-coding to eliminate all 'possible' buffer overflow situations is a *big*
> RB> job. The required field-length checking for every multi-byte copy/move
> RB> operation does have a significant negative impact on performance, as well.
>
> Getting "owned" can also have a significant negative impact on
> performance. Of course, maybe the attacker will be benevolent, so
> perhaps all will be okay...
>
> Correctness before speed. Who wants a machine that just gives bad
> results faster?
"Upgrades" or 'fixes' that cause a machine to run noticably _slower_ than
the 'down-rev' machine are a really good way to alienate customers. Especially
thosw whose machines are running at nearly 100% capacity before the "upgrade".
If there is a way to render the matter 'harmless' -without- the performance
hit of the 'do it in the theoretically correct manner', *and* that 'defanging'
solution can be delivered in weeks (vs. -years-, for a 'theoretically correct'
approach), there is _clear_benefit_ to taking the 'incorrect' route. Benefit
that accrues both to the manufacturer _and_ to the CUSTOMERS.
> RB> Merely _identifying_ the 'tainted' (by being in contact -- directly or in-
> RB> directly -- with 'user-supplied' data) data-structures is a task measured
> RB> in man-years. As is isolating _all_ the points where such tainting occurs.
>
> Sounds like a pretty good argument for "do it right the first time".
"Irrelevant", when the subject under discussion is pre-existing code that
is _known_ to have (at least one) buffer-overflow problem. "Do it right
the first time" is a _really_ difficult target, when the consensus as to
what 'do it right' *means* has changed _since_ the code in question was
first written. <wry grin>
I'll also quote:
"In any application, discovered bugs are finite in number,
UNDISCOVERED BUGS, however, are, by definition _infinite_ in number."
> RB> Then, and only then, can you begin to -plan- how to remove the taint, whether
> RB> by sanity-based bounds-checking, 'clipping' to known limits, explicit length
> RB> checks, or whatever else is appropriate.
>
> Hopefully the code is modular. e.g., running cscope and searching for
> strcpy(3) invocations is easier than tracking down implemented-in-place
> equivalents.
*snicker* _That_ only addresses one small subset of the underlying problem.
strncpy() and/or memcpy() can also corrupt memory -- when the 'length' param
is larger than the receiving field, for example. This can happen, for example,
when the 'length' is taken 'on faith' from user input, and not validated.
