Book review: The Art of Software Security Assessment

The book is divided into three sections. Each section is once again divided into several chapters. There are a total of 18 chapters in the book.

The first section is called Introduction to Software Security Assessment. In four chapters (Software Vulnerability Fundamentals, Design Review, Operational Review, and Application Review Process) the fundamentals of software security and software security assessment are introduced. In these chapters the authors give a brief definition of software security, what kind of vulnerability classes exist (low level, design problems, communication protocol problems, ...) and how to identify and document these vulnerabilities in software you want to review.

In the second section of the book (Software Vulnerabilities) the authors explain what kind of low-level vulnerabilities exist and how to identify and correct them. The section starts with a chapter named Memory Corruption that deals with problems caused by stack and heap overflows and related concepts. Next is a chapter about C Language Issues. The primary focus of this chapter lies on arithmetic problems caused by things like type conversions and arithmetic boundary conditions. Related issues like uncertain order of evaluation, potential precedence problems and pointer arithmetic are explained too. The following chapter (Program Building Blocks) is all about control flow problems. Are all variables initialized properly, no matter how control flow is transferred within a function? How about the control flow between functions? Do any execution paths exist that break assumptions or conditions demanded by called functions? Chapter 8 (Strings and Metacharacters) is completely different. This chapter talks about vulnerabilities caused by different string encodings. Special focus lies on dangerous metacharacters that might change the content of strings in ways software developers never expected and therefore never filtered. The next four chapters are about OS-dependent vulnerabilities. Two chapters (UNIX I: Privileges and Files and Unix II: Processes) are about common UNIX vulnerabilities, the other two chapters (Windows I: Objects and the File System and Windows II: Interprocess Communication) talk about Windows. The last chapter of the second section (Synchronization and State) is once again platform-independent and lists some problems that arise in multi-threaded applications.

The chapters 14 to 18 form the third section of the book, "Software Vulnerabilities in Practice". In this section, the authors explain potential issues on higher abstraction levels than in the second section. Chapter 14 (Network Protocols) gives a brief introduction to the network protocols IP, TCP, and UDP and how to work with these protocols. Chapter 15 (Firewalls) explains the differences between different kinds of firewalls and what common attacks against firewalls look like. Chapter 16 (Network Application Protocols) is a continuation of the chapter 14 on a higher layer of the OSI model. Higher level protocols like DNS or ISAKMP and technologies like ASN.1 are discussed. The last two chapters deal with Web Applications (Chapter 17) and Web Technologies (Chapter 18). The first of the two chapters deals primarily with HTTP. The authors explain the HTTP protocol and what kind of vulnerabilities software engineers have to look out for (SQL injection, cross-site scripting, ...). The last chapter gives a brief overview of the programming languages Perl, PHP, Java, ASP, and ASP.NET which are often used to generate dynamic websites. In this chapter the different technologies are compared and the authors show how to avoid common attacks against websites in each of the mentioned languages.

So much for the description of the book. Here are my thoughts about it. What I really liked about the book is that the authors show many examples of vulnerabilities that come from real programs. Only rarely did the authors write their own example code. This gives the reader the feeling that the issues discussed in the book really matter. If these vulnerabilities exist in popular software like the Apache HTTP server, OpenSSH or Sendmail and they were successfully exploited there, similar problems might exist in your own code. In the first few chapters of the second section it's rare to go more than 2 pages without another source snippet from some kind of prominent open-source project. Unfortunately this changes in the later chapters of the second section. Especially the chapters about Windows-specific vulnerabilities seriously lack real life examples. The contrast is so notable that I've started to wonder why that's the case. Maybe all these different potential vulnerabilities introduced in the later chapters of the second section are so rare compared to the ones introduced in the first section that they don't really matter in the grand scheme of things. Or maybe it's because the vulnerabilities from the earlier chapters are platform-independent and therefore there are a lot more open source projects to get example code from. I just don't know. But the contrast between the first part of the section and the third part is weird.

Let's get back to the examples from the first part of the second section. Those were well-chosen in my opinion. The highlight was certainly a vulnerability from l0pht's Antisniff tool. Starting on page 250 of the book the authors tell the story of a buffer overflow vulnerability in Antisniff that was discovered by TESO and quickly fixed. Except it wasn't fixed. The fixed version was still exploitable. Another fix was issued and it was still exploitable. It took four of five fixes to correct the problem. The authors of the book do a great job to walk the reader through the different fixes and how each new version introduced new subtle problems. I think that part was really an eye-opener for how careful you have to be when you write programs or when you review them for vulnerabilities. The best way to introduce a bug is to fix another one.

Another thing I liked was the level of detail of the book. It's full of well-designed figures and relevant tables that illustrate what the authors are talking about. Furthermore there are often small boxes that give brief explanations of concepts readers might not be familiar with. This is very helpful to readers who are new to software reviews and aren't familiar with related concepts a software reviewer will probably encounter sooner or later.

Many of the tables I mentioned in the last paragraph explain structured approaches to finding vulnerabilities. The authors don't just show you how buffer overflows work or things like that. They also show you how to document what you've found in ways that make it easier to connect your earlier findings to the part of the source code you're currently reviewing. They tell you how to take notes about important aspects of a function, like expectations about parameters or return values. They tell you how to take notes about potential control flow problems. They tell you how to document exploitable vulnerabilities you've found and so on. This is a critical point for me. There are already many sources (both books and websites) that explain different vulnerability classes and why/how they're exploitable. This book gives the reader more than that though. It gives the reader a structured approach to finding and documenting potential problems. I consider that aspect of the book very valuable.

To summarize, I think the book is a great book. It's as comprehensive as you'd expect a 1100+ Addison-Wesley pages book to be. I started to read it not from the perspective of a vulnerability researcher who wants to find vulnerabilities but from the perspective of a software developer who wants to write code that survives a critical review by vulnerability researchers. However, while I was reading the book my focus shifted and I started to feel that reviewing code could actually be pretty fun (god knows how the authors of the book manage to make looking through someone else's source code an exciting experience, but they do). It's entirely possible that I take one of my own larger projects one day and review the code according to the guidelines introduced in the book.