Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Networking Pearl Harbor in the Making

  • From: Edward B. Dreger
  • Date: Sun Nov 13 13:57:45 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@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.




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.