Re: Networking Pearl Harbor in the Making
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.
RB> Date: Fri, 11 Nov 2005 11:03:44 -0600 (CST) RB> From: Robert Bonomi RB> "Upgrades" or 'fixes' that cause a machine to run noticably _slower_ than RB> the 'down-rev' machine are a really good way to alienate customers. Especially RB> thosw whose machines are running at nearly 100% capacity before the "upgrade". True, but saying "sorry, there's no fix for this vulnerability" doesn't win many points, either. Given a choice between "no fix" and "may need new hardware", which would you choose? RB> If there is a way to render the matter 'harmless' -without- the performance RB> hit of the 'do it in the theoretically correct manner', *and* that 'defanging' RB> solution can be delivered in weeks (vs. -years-, for a 'theoretically correct' RB> approach), there is _clear_benefit_ to taking the 'incorrect' route. Benefit RB> that accrues both to the manufacturer _and_ to the CUSTOMERS. Definitely. If there is not such a way... then what? RB> "Irrelevant", when the subject under discussion is pre-existing code that RB> is _known_ to have (at least one) buffer-overflow problem. "Do it right RB> the first time" is a _really_ difficult target, when the consensus as to RB> what 'do it right' *means* has changed _since_ the code in question was RB> first written. <wry grin> It's relevant in the sense of learning from the past. I agree that, operationally, one could make comments about barns and horses that have left. If "do it right" has changed, does that mean "correctness" did not originally include "do not allow non-trustworthy input to alter behavior"? If this is so, then the original definitions were short-sighted. RB> > Hopefully the code is modular. e.g., running cscope and searching for RB> > strcpy(3) invocations is easier than tracking down implemented-in-place RB> > equivalents. RB> RB> *snicker* _That_ only addresses one small subset of the underlying problem. Very good. Quick grammar lesson: "e.g." stands for _exempli gratia_, meaning "for example". One could reasonably conclude that I was giving one example rather than attempting a comprehensive coverage of all vulnerabilities. RB> strncpy() and/or memcpy() can also corrupt memory -- when the 'length' param RB> is larger than the receiving field, for example. This can happen, for example, RB> when the 'length' is taken 'on faith' from user input, and not validated. Of course. Let's dispense with the straw man, though. My point was that, hopefully, code is written in a way that lends itself to quick searching. In no way did I say "using strncmp() is the ultimate answer to all security vulnerabilities". To claim such would be asinine. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
participants (2)
-
Edward B. Dreger -
Robert Bonomi