Review: Exploiting Software [LWN.net]

The world is full of books on how to secure systems, how to write secure code, and how to deal with breakins. There are rather fewer books that go into details of how to compromise software and carry out breakins. That gap has now been filled by Exploiting Software: How To Break Code by Greg Hoglund and Gary McGraw. This book's purpose is not to help the crackers; those people, according to the authors, already know about the techniques described here. Instead, the authors wish to help programmers and system administrators achieve better security through an understanding of how security failures happen.

To that end, this book covers a number of ways of attacking software. Direct reverse engineering gets a full chapter, much of which is dedicated to things you can do with the Windows debugger. There is a chapter on server attacks; it looks at carefully crafted input, configuration attacks, filesystem browsing, poor authentication schemes, etc. The chapter on client-side attacks covers cross-site scripting, embedded control characters, and more. The creation of malicious input gets a chapter of its own, where issues of how to track what a server does with input, tricks with character encodings, and more are discussed; this chapter also looks at how to get malicious input past intrusion detection systems. Buffer overflows and format string vulnerabilities are discussed in detail; interestingly, the authors claim that format string vulnerabilities were known to the "black hats" for years before being more widely "discovered" and, mostly, fixed. The book finishes with a discussion of root kits.

If you are a cracker wannabe looking to learn the trade, this book might provide a good start - though you will still have to fill in a lot of the details yourself. This book is not a simple cookbook for crackers, though some of its advice ("Also, remember that a Web server will create log files of all injection activity, which tends to stick out like a sore thumb. If this pattern is used, clean the log files as soon as possible.") is not necessarily useful for anybody else. The coverage of the book is not entirely complete either; it has little space for kernel attacks, SQL injection, or exploit generation tools, for example. While Linux is often mentioned, the bulk of the discussion uses Windows for its examples (though almost all of the concepts discussed apply equally to either system). Even so, Exploiting Software is a worthwhile addition to the bookshelf of anybody interested in security issues - as most of us should be.

(Log in to post comments)

Review: Exploiting Software

Posted Apr 29, 2004 14:25 UTC (Thu) by dwheeler (subscriber, #1216) [Link]

This review starts with "The world is full of books on... how to write secure code". Ah, if only that were true.

The truth is that there are few such books; I count only 3, if you emphasize books that actually show you specifically what to do (instead of vague, general knowledge). To my knowledge, I wrote the first such book, the Secure Programming for Linux and Unix HOWTO, though since it's freely available on the web it's been updated many times since its original release. More recently there's "Building Secure Software" by John Viega and Gary McGraw, and "Writing Secure Code" by Michael Howard and David LeBlanc (Windows-centric). I think all 3 are good; get all 3! Viega has a "Cookbook" that you can view as an appendix to his previous book, which is a useful addition (but you need his first book to truly employ it). Even adding that book, that's 4... not a world-filling number. There are a very few related books like the The Open Web Application Security Project (OWASP) document that emphasize process and high-level concepts. That's fine, but since they don't explain exactly what kinds of things you should and shouldn't do; developers who read only those kinds of books will still make the same egregious mistakes.

And that's it. Certainly not a world filled with those kinds of books!! There are actually a lot of books on how to break into systems ("Hacking Exposed", etc.) already. A good entry in a more crowded field is fine, of course, and McGraw co-wrote one of the books on writing secure programs. Don't get me wrong; I'm glad that more developers are beginning to understand how their systems get broken into, because that may motivate them to write code that prevents it.

But that's not enough. We need developers to know how to prevent such attacks, not merely how such attacks are performed.

Review: Exploiting Software

Posted Apr 29, 2004 18:35 UTC (Thu) by dang (subscriber, #310) [Link]

"This book is not a simple cookbook for crackers, though some of its advice ("Also, remember that a Web server will create log files of all injection activity, which tends to stick out like a sore thumb. If this pattern is used, clean the log files as soon as possible.") is not necessarily useful for anybody else"

This isn't entirely true. Reminders to clean log files should serve as a wakeup call to any sysadmins who aren't pushing their logs offhost to a log server ( e.g. syslog-ng over ssl ).

Inconsistent PoV?

Posted Apr 30, 2004 21:08 UTC (Fri) by AnswerGuy (subscriber, #1256) [Link]

The quoted passage seems to highlight an inconsistency in the authors' point of view. The purport to be a book for white hats to learn black hat techniques and then offer advice directly to the black hat.

Personally I think it's a nitpick. However, the authors could have retained consistency beyond reproach by reframing this comment as advice to the systems administrators: "Remember that the cracker will try to gain write access to the system and webserver logs ASAP after they've successfully gained access to the system. They know that there injection activity can stick out like a sore thumb and will want to remove or obfuscate these patterns to delay the intrusion's detection"

However, that lacks brevity and pith!