Buffer overflows have been a staple of attacks ever since Aleph1's infamous paper "Smashing the Stack for Fun and Profit" was published in Phrack back in 1996. Certainly the BO had been around before the paper, but the explanation with code gave it a boost. Other papers have been published since then. Serious work has been done to prevent it from working, such as the non-executable stack, and several good books have been published showing how to write code that is not so vulnerable to it. Foster and company have significantly expanded the knowledge base with this book. The book looks a lot like the original paper: clear explanations, assembly code, C code and an obvious clear understanding of what is going on under the hood.

The book takes advantage of the newer approaches, lots of new exploit code, and distinctions between a stack and a heap.It also highlights the continuing success with attacks on format strings which still provide easy targets. This is a bit distressing since much has been written about them, including relative ease of preventing them, especially with the tools available.

The authors estimate about 20% of successful exploits are buffer overflows, which is a pretty high number in absolute terms. The basic attack still looks the same: write past a buffer boundary, depositing code of your choosing, mostly some that will start a shell with privileges. The newer thinking seems to be more about finding better ways to accomplish it. Buffer overflows are operating system specific and hardware specific if you use assembly language, the language of choice. It helps to have a disassembler handy while developing or trying to figure what happened to you.it It also helps to understand memory addressing and management. The book shows some neat techniques that take advantage of allocating and deallocating memory.

An important facet of understanding attacks and prevention is the operating systems differences. As an example, Microsoft Windows does not use system calls like the various flavors of Unix do. That means that your BO code or your preventative measures will be different. No worries here, the book does a great job showing the unique aspect of each operating system, as well as the code required. In fact, the book has a large number of examples of exploit code, with line by line explanations. It is not enough to publish code. To get an understanding, one needs to be able to clearly explain the concepts involved, as do the authors, thus presenting the bigger picture of the problem

I really like this book and highly recommend it, but a small caveat is in order. It pushes Application Defense a bit too much and the web site does not actually have the code in the book as promised. Since this is generally considered an extra, this not a big deal - it just means you have to type.