PDF
Buffer Overruns and Everyone
I was pleased to read Rodney Bates’ “Buffer Overrun Madness” (May 2004). The choice of programming language has a significant effect on the vulnerability of networking software. In addition to buffer overruns, the single largest category of vulnerabilities, there are also large categories of vulnerabilities related to signed integers that silently overflow and to spawning new processes.
Jeffrey R. Carter, Apache Junction, ArizonaIt is not up to the compiler to ensure memory protection; hardware architectures already allow a design in which it is possible to control read-write-execute access rights with fine granularity (at least a memory page). In addition, kernel-mode code and data already enjoy a high level of such protection on practically every current platform. The application memory space, however, is not protected in the same manner by default.
Vadim Kavalerov, Philadelphia, Pennsylvania
Another Look at Security Problems
I enjoyed Marcus Ranum’s article “Security: The Root of the Problem” (June 2004). However, I must challenge his statement that nobody has ever come up with the idea of “making malloc() and free() stub-calls into a generic garbage-collected memory allocator and doing away with C memory management altogether.” Indeed, such a scheme, “the Boehm-Demers-Weiser collector” (http://www.hpl.hp.com/personal/Hans_Boehm/gc/), was published in 1988 and has been improved ever since.
Brian Goetz, Menlo Park, California
MARCUS RANUM REPLIES: Microsoft’s addition of garbage collection to C# may be the first real breakthrough in getting memory management out of the hands of C programmers. The fact that something so useful has not found its way into the most popular environments says a great deal about our priorities when producing good or secure code.
Marcus Ranum’s article contains sweeping statements about “alternative programming languages,” which apparently include Java. In addition, the statement “[ActiveX] bypasses security entirely by making it easy to blame the user for authorizing bad code to execute” implies that ActiveX is Microsoft Internet Explorer. Finally, when Ranum discusses garbage collection, he rhetorically questions garbage collection in C or C++. In fact, work has been done on this.
Ryan McLoughlin, Somerville, Massachusetts
MARCUS RANUM REPLIES: As far as alternative programming languages, Java is another programming language, and there’s not much more to say about it than that. The real issue is that nobody is going to jump over to a new programming language just because people scream about security. ActiveX and Internet Explorer are separate things—the point is that many users are quite happy with a downloadable code metaphor providing security, which is largely window dressing once you get past authenticating the signer of the code. With regard to garbage collection, it’s not commercially mainstream. Indeed, until Microsoft ships with it turned on by default in MS-C++, it’s just a curiosity.
Very early in my career as a software engineer, I learned that the difference between a good software engineer and a great software engineer has to do with good habits, which are a skill that’s not taught in the universities. (Write that descriptive error message now, not later when you’ll forget about it.) Code reviews are invaluable source of training for dealing with such issues.
Robert Angelino, Corona, California
MARCUS RANUM REPLIES: You’re absolutely right! Mentoring junior software engineers is crucial—and it’s got to be done through a judicious mix of procedures, peer pressure, and technology. I used to assign all my engineers the task of reading Tom Van Vleck’s articles on software engineering (http://www.multicians.org/thvv/).
We edit letters for content, style, and length.
To submit a letter, e-mail us at [email protected]
Originally published in Queue vol. 2, no. 6—
Comment on this article in the ACM Digital Library
© ACM, Inc. All Rights Reserved.