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.
