April 26, 2004

Book Review - Exploiting Software: How to Break Code

Unless you know the threats to which you are susceptible to, you will never be able to design secure systems. Technology changes, as do the attackers. Exploiting Software: How to Break Code has driven that home for me as it truly shows how in the vast knowledge I have on the subject I too am always able to learn more.

Gary and Greg did a great job in this book. It is well thought out and meticulous in the detail on showing just how to break code. If you design secure systems YOU MUST READ THIS BOOK. Hell, even if you donít you should read this book.

If you have been following previous blog entries you will know I have been raving about this book for some time. The reason I didnít post a review sooner is that I wanted to read the book twice to make sure I really understood some of the key components within the book in areas I wasn't the strongest in. And it was well worth the double take. I think I learned more the second time around when I more understood the concepts.

This book is not for the faint of heart. Although you can walk away with a lot at any level of programming knowledge, to really benefit from this book you have to have a strong understanding of assembler. Without it half the book will be useless to you as you wonít understand the concepts presented. Perhaps a quick sidebar to discuss many of the common assembler instructions could have been helpful in the book to someÖ or even just reading an asm primer beforehand would help. Luckily I enjoyed assembler in universityÖ it was one of the courses I got 100% in back in the day.

Which gets me to a point that I think other people will end up bringing up if they read the book. If you canít understand the assembler in the book, you wonít get how to actually exploit code. In other words, if you pick up this book assuming you will walk away with a step-by-step guide with snippits of code to put together your own 'recipe' exploit you have another thing coming. Although there are some really good snippits ranging from payload insertion for overflows to rootkit mapping (and lots of other neat little tidbits in between) the reality is that this book shows you how to look for weaknesses and then attack them. I hold that to Greg's rootkit chapter which had some really detailed code on kernel injection techniques.

Which gets me to one of my favorite parts of the book. As someone who writes kernel code in Windows I REALLY enjoyed the section on patching the Windows kernel to remove all security. It was interesting to see how a couple of bytes could bypass the entire security manager in Windows, and focusing on SeAccessCheck was brilliant! However, I think this section was also a detriment to the authors. The book seemed quite professional right up until this point. We all know the weaknesses in the Windows environment and we all have concern about it. But the 'personalized' negative attitude and berating of Windows and even the US Navy had no place in this book. I'm not here to stick up and defend Microsoft on the subject, but I expected more professionalism from the authors as it relates to computer security here... they should have taken the high road on the subject. I can just as easily show how a rogue Linux kernel module can wreak havoc on a system just as the code presented here can. But its futile to spew forth useless drivel about it. Let's not muddy the waters and focus on the real issue of exploiting code, and keep the personal tainting out of it. If I didn't know the author's work better this could very easily have damaged the credibility of the section, perhaps the entire book. So for others reading the book, just ignore the personal tainting and understand the methods involved. Yes, being able to do a bit flip to disable the entire security is bad. Better compartmentalization is good. :)

If you are in anyway involved in red-team testing and want to know how to approach a target this book provides crucial knowledge and even some good insight on using tools like IDA to assist you. And if you are a developer this book will help you think more defensively about your approach to code.

What could I see done better? Well, it was nice to see how to BREAK code, but I would like that put into perspective on how to fix it. Although this book is said to be a great companion on Garyís book on Building Secure Software I think more should have been presented to map the two topics better. As an example there was one case where discussion ensued about fault injection techniques with very little discussion on defending this with user input validation testing. Mapping those concepts better could go a long way to more educate developers. Of course, that wasnít the intent of the book, and this is just my opinion. I am always for educating the developers about secure programming every chance we can get!

Overall, a great book. And one I recommend to the serious computer security software developers out there.

4 out of 5 stars.

Posted by SilverStr at April 26, 2004 10:19 AM | TrackBack
Comments

Definitely sounds like one for "the list".

As for an assembler primer, you could do a lot worse than Matt Pietrek's MSJ article "Enough Assembler To Get You By" (http://www.microsoft.com/msj/0698/hood0698.aspx).

Posted by: Paul Bartlett at April 27, 2004 03:39 AM

Check out the HOWTOS. (Actually, I am just trying to put in some test data)

Posted by: SilverStr at May 31, 2004 04:24 PM