Networking Pearl Harbor in the Making
Edward B. Dreger
eddy+public+spam at noc.everquick.net
Sun Nov 13 18:56:33 UTC 2005
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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
More information about the NANOG
mailing list