From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5bc4be576204aa20 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!news.germany.com!news.belwue.de!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: Buffer overflow Article - CACM Date: Sun, 13 Nov 2005 15:58:13 +0100 Message-ID: <87psp4a92y.fsf@mid.deneb.enyo.de> References: <2421265.tcOOYmdnmL@linux1.krischik.com> <43772913$0$21943$9b4e6d93@newsread2.arcor-online.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: albireo.enyo.de 1131893902 19292 212.9.189.177 (13 Nov 2005 14:58:22 GMT) X-Complaints-To: Cancel-Lock: sha1:c2SNHitSUa742WjekWaHKleQF84= Xref: g2news1.google.com comp.lang.ada:6359 Date: 2005-11-13T15:58:13+01:00 List-Id: * Georg Bauhaus: > http://doi.acm.org/10.1145/1096000.1096004 > > The authors refer you to their site, in the final sentence of > their article. If you look at their "front page", the motivation of > their analyses will become clear. Please tr -d ' ' in > w w w . s m a s h gu a r d . or g > > Some quotes: > > "One way to prevent programs from having such vulnerabilities is > to write them using a language (such as Java or Pascal) that performs > bound checking. However, such languages often lack the low-level data > manipulation needed by some applications. Therefore, researchers have > produced "more secure" versions of C that are mostly compatible with > existing programs but add additional security features. Cyclone [5] > is one such C-language variant. Unfortunately, the performance cost > of bounds checking (reported in [5]) involves up to an additional > 100% overhead." The tables in that paper do not justify the 100% figure, and the paper shows that some of the programs were incorrect, presumably because the authors failed to include run-time bounds checks. The "fat pointer" approach used by Cyclone is not representative of typical compiler implementations of bounds-checked array types, either. > "Dynamic protection techniques can be costly in terms of overhead, Yeah, sure. Bounds checks are costly, so lets get rid of them and just use obfuscation techniques to prevent code injection. The truth is that you have to check things at some point, and manually coded bounds checks have been shown to be error-prone (more than compiler-generated ones). For most applications implicit bounds checks are probably a win. The authors show a profound lack of industry experience. In real-world Internet applications, a typical non-exploitable buffer overflow is still a very serious defect because it affects availability. Shifting bugs from crash-and-control to crash-only isn't such a tremendous improvement, especially in environments which use multi-threading instead of multiple cooperating (but isolated) processes.