Building Secure Software. How to Avoid Security Problems the Right Way
by John Viega and Gary McGraw
Addison-Wesley, 2002.
Index. Bibliography. 3 appendices. 493 pages ISBN 0-201-72152-X LoC QA76.76.D47 V857. 2001 $54.99

Reviewed by  Robert Bruen   January 9, 2002 

If you are tired of hearing about buffer overflows and other consequences of software designed or written without much thought to security issues, give a copy of this book to your favorite software vendor. No one really expects perfect, bug-free software, but we should expect that the trivial things are fixed at the outset of software design. Perhaps it may be little worn out as an analogy, but constructing buildings still offers some useful lessons for software builders. For example, we all know that foundations are real important. We also know not to use sand as the primary material, just as know that earthquakes effect buildings, so we take some care to account for this in the building's design.

By now everyone knows that buffer overflows are a mostly preventable problem, just as we know that storing usernames and passwords in ASCII files which are accessible to the world is a problem. It is had to believe that buffer overflows are still being discovered, so the question has to be whether the authors did not know how to handle this while writing or whether they just did not pay attention. In any case, Viega and McGraw have spelled out quite clearly why one should care and how one should do it. They have also gone beyond the buffer overflow problem, providing good coverage secure software.

There are only a few books published in this area and a bit more on the net, so this is welcome addition to the security library. One can only hope that this will grow into a serious branch of software development. These problems have been around for a while, for example Aleph1 released a paper in 1996 (Smashing the Stack for Fun and Profit) almost six years ago, a long time in the technology world. Some things have moved very along very quickly, but writing secure code has not been one of them. Attacking code, on the other hand has caught on like the plague. The time has arrived for a response from software vendors that does more than complain about people finding security holes in their software.

This book has detailed information on system library code that should be avoided with the replacement code identified. It in clear wording: You should not system call X because of problem Y, use system call Z instead. There are examples of attack code with explanations of how and why it works, as well as methods for avoiding the problems. Of course, not everyone appreciates attack code being made public, especially with analysis, but it is helpful to see the details if you will be writing code that needs to prevent such an attack.

The authors have reminded us of another old problem that seems to have been forgotten, that of trust and input validation. In the early days of programming, especially for business, one always tried to make sure that if a number was expected as input, a number was what was allowed. And that number would be within a range. The extension today is for things like file locations in a URL and such, but is goes beyond that to programs calling other programs. If your program is secure, you cannot expect the program you call to be secure, which appears to happen a little too often.

Building Secure Software is a highly recommended book that does what it says it will do. If only it gets read.