nanog mailing list archives
Re: Networking Pearl Harbor in the Making
From: Robert Bonomi <bonomi () mail r-bonomi com>
Date: Fri, 11 Nov 2005 11:03:44 -0600 (CST)
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.
Current thread:
- Re: Networking Pearl Harbor in the Making, (continued)
- Re: Networking Pearl Harbor in the Making Todd Vierling (Nov 07)
- Re: Networking Pearl Harbor in the Making Christian Kuhtz (Nov 07)
- Re: Networking Pearl Harbor in the Making Chris Woodfield (Nov 07)
- Re: Networking Pearl Harbor in the Making Joseph S D Yao (Nov 07)
- Re: Networking Pearl Harbor in the Making Joseph S D Yao (Nov 07)
- Re: Networking Pearl Harbor in the Making Edward B. Dreger (Nov 11)
- Re: Networking Pearl Harbor in the Making Edward B. Dreger (Nov 13)