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: Fri Nov 11 09:18:46 2005

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?


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".


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.


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:
[email protected] -*- [email protected] -*- [email protected]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.