Re: Buffer overflow Article - CACM

[Florian Weimer <fw@deneb.enyo.de>]

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