The true concept of buffer overflow is that of a new type of programming error that was (possibly unwillingly) invented by the authors of the programming language C.

In languages defined at about the same time, automatically checking all array references was considered the normal way of life; languages like Modula-2 or Ada provided strong mechanisms for such checking. Although it might seem foolish to wear a life preserver while learning to sail in port, and then remove it when sailing to the open sea, the equivalent of this was frequently done in programming, for the sake of efficiency. Excellent techniques were designed, however, to improve the efficiency of range checking, thanks to the presence at compile time of all the needed information. Static-analysis techniques were also designed, which completely avoided the inefficiency drawback wherever possible.

These events occurred about 30 years ago. The safe languages have since disappeared, or are confined in some specific niches, while C is ubiquitous, and used for programming the most security-sensible applications. Thus, it is no surprise that myriads of hackers are using this fundamental drawback to exploit weaknesses in myriads of these ubiquitous programs, and to gain superuser privileges on attacked systems.

This paper does not attempt to express any opinion about this state of affairs. Buffer overflow vulnerabilities are considered a natural fact of life, like hurricanes, or tempests. However, the authors do a very good job of describing, at length, the full problem, of detailing its various aspects, and of explaining the main approaches taken in trying to avoid it.

Starting with the assumption that existing programs should not be changed, the authors demonstrate how several different techniques can be used to address the buffer overflow problem. Some need to recompile the source programs, others need only to redo the link edition, and others need only for the program to not use static linking. These three categories represent a spectrum from the most efficient to the least efficient, but also from the least safe to the most. A specific method proposed by the authors has the characteristics safe, but not very efficient. A less-known but related vulnerability, format string overflow, is also described, though with fewer details and solutions than the main topic of interest.

A small detail makes reading this paper more difficult than necessary: there are 33 figures in the 38 pages, but almost none appear on the same page as their corresponding explanations.

The references have an interesting characteristic: only a minority of them occurs in conference proceedings, and none at all in a normal journal. Certainly, this paper will be cited many times, and it will deserve it.