Olivier Langlois's blog

Beside Bruce Schneier books, this is the second software security book that I am reading. The first being Building Secure Software: How to Avoid Security Problems the Right Way and I have prefered this one because it provides more concrete examples. The book consists of over 20 chapters covering different security areas. As a software developer, some chapters appeared less relevent and less interesting to me and I guess that it is because these chapters are geared principally toward testers.

However, at least 2 chapters should be extremely interesting and valuable to developers like myself. It is the chapters that demonstrate with step by step tutorials how a hacker would do to exploit buffer overflow and format string problems. I was already familiar with buffer overflows and I had read a similar chapter about them in Building Secure Software: How to Avoid Security Problems the Right Way but the format string exploits were new to me.

As expected since the book is published by Microsoft Press, the book has a strong bias torward Microsoft products (ie.: .NET and ActiveX controls security) but the presented topics are general enough to make this book very valuable even for users of other OSes and/or development tools.

It is a good book but with the exception of the chapter on buffer overflows, my perception of the book is that it focus mainly on the theory of software security. As someone who has an engineer formation, I have a preference for books more pratical with more concrete examples. For this reason, I did prefer Hunting Security Bugs.

Consider the following program:

#include <stdio.h>

void f(int i)
{
    switch(i)
    {
    case 1: printf("case 1\n");   break;
    default: printf("default\n"); break;
    case 2: printf("case 2\n");   break;
    }
}

int main(int argc, char *argv[])
{
    f(2);
    return 0;
}

What will be the output?
Intuitively because the cases might be evaluated in the order that they are declared to make 'fall through' possible from one case to the next one by omitting the break statement, the default case might be executed when i value is 2. I have checked my C++ reference book and my C reference book. The C++ one is silent one this issue but I have found this statement from 'The C programming language' book on page 58:

The case labeled default is executed if none of the other cases are satisfied....Cases and the default clause can occur in any order.

I still had doubt so I have compiled the sample program with Microsoft Visual C++.NET 2003 and with gcc version 3.4.4. Both compilers are compliant with what is specified in 'The C programming language' book and the case 2 is executed. Could it be possible that a compiler with a naive implementation create code that behaves as I intuitively reasoned? Maybe so for staying on the safe side and to make the code unambiguous for the maintainers, a good guideline is to always place the default clause at the end of the switch block.

Windows sockets are not like BSD sockets. The book explains very well the different specific modes into which winsock can be used: Blocking mode in a dedicated thread, asynchronous mode using Windows messages and Overlapped I/O that removes some memory copying when passing buffer to send/receive data from/to sockets. It also covers the Socket classes provided with MFC. In my opinion, this book covers very well the details specific to Windows version of the socket API and that will allow the readers to take advantage of this socket API version.

ATL is an interesting C++ framework to easily create COM classes. It uses extensively the C++ templates and is coupled with Visual C++ wizards to automate the writing of skeleton code of an ATL project. However there is not much documentation coming with VC++ on ATL and there are so much options in the wizards dialog windows that unless you know what you are doing, you will probably not do the right thing. This is where this book comes in.

First, one of the coauthor, George Shepherd, is also the coauthor of the book MFC Internals that I really liked. This book does a good job to guide you through the main ATL features. My only complain is that, like almost every other book on COM that I have read, it assumes that you know nothing about C++ and COM and takes the first 2 chapters to introduce you these topics and that represents almost 100 pages of prerequisite material that should have been found only in a introduction book IMO.