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.