Customer Reviews

Exploiting Software: How to Break Code

5 star:		(18)
4 star:		(7)
3 star:		(2)
2 star:		(3)
1 star:		(0)

 

 

"Exploiting Software" purports to be a book aimed at helping software
professionals understand the security risks they face; it uses the
pedagogical device of teaching how software can be attacked to
achieve the goal of explaining how secure software should be
built. Unfortunately, I think it fails both as a guide to building
secure software and as a guide to being a black hat hacker.

Most of "Exploiting Software" reads more like a book proposal than a
completed work: too detailed in places (do we really need a dozen
pages on writing plugins for the IDA Pro Disassembler?), not detailed
enough in others, and generally not well organized. Far too often, the
reader is simply told that an exploit exists, and is then directed to
the original source for details. Worse, the original sources are often
white papers, personal web sites, and conference proceedings -- things
that are either hard to obtain, unlikely to be available for long, or
both. As a result, the reader learns nothing.

The preface to "Exploiting Software" explains that this is a companion
volume to "Building Secure Software," written by the same Gary McGraw
with another co-author, and this helps to explain the main failings of
this book. I must admit that the last two chapters, "Buffer overflow"
and "Rootkits", are better than the rest; they provide plenty of
concrete details. But two chapters aren't enough to vindicate this
fairly shallow work. For my money, I expect a book that can stand on its
own.

I'm an IT auditor (my main interest area is systems software). The premise of the book, that application security is now the key risk area for exploits is spot on. Exploits of applications can be devestating. This book describes basic attacks on application software; unfortunately the level of detail varies from example to example making it a little difficult to follow. It does provide valuable examples for those developing software of potentail problem areas and common faults. It is is also of potential value in planning penetration tests. There is no real coverage of secure coding practices and how to integrate security into the development process though. The book is worth getting but provides far from exhaustive coverage of code expoitation.

I admit it, I was expecting a lot of this book. I've seen one of the co-authors, hoglund, speak at various security conferences in the past, and he is one of the top minds in the industry. I was therefore very excited to find he was writing a book on "exploiting software".

That being said, I was led to believe that this book would actually teach me how to "exploit software" --- that is the title, isn't it? The first two chapters are kind of overview, talking about historical flaws in things like embedded processors, and then a lengthy tutorial on somewhat obscure topics, such as writing plugins for the popular belgian disassembler, IDA Pro. While this is all fine and dandy, at this point in the book you will start to read faster and think "when do I get to learn how to "exploit software", and write some friggen exploits?"

Well, I was hoping to find that content later in the book (obviously contributed by mr. hoglund), but all I found was some terse overviews on how these exploits are possible. NOT how to actually write them, or use them in practice. This is where I was letdown, and may I even say, misled by the marketing material for the book.

I do have to say, the final section on writing a windows xp rootkit does have some concrete examples, and is highly interesting and informative. But, it remains the only truly hands on and practical portion of the book. This book should have been titled, AND marketed as "The Theory of Software Exploitation + A Good Chapter On Rootkits".

'Exploiting Software' is a quite disappointing book. It is not well organized and repeats itself very often, there's no thread and the authors always lose themselves in trivial things. Whenever it started to get interesting the book stopped short of going into details. The only slightly sophisticated chapters are the ones at the end, about buffer overflows and the XP rootkit.

I found that often code fragments are insufficiently described or not explained at all. This is a no-no in writing software, and it is all the more when writing a book about software (I can easily download some code and then wade through the code myself, what's the added value of the book?). On the other hand, simple tasks like appending a line to a Unix text file are explained exhaustively. Or, the book contains several pages about a code to display sampled data graphically. Why would I want to read this in a book about software exploits?

Overall, the book fails in the most important aspect: to bear the reader in mind. It seems that the authors just wanted to write a book, a thick book. Among the target audience mentioned in the book, i.e., programmers, consultants, managers etc. only programmers with absolutely no background in security may appreciate the book.

Go check the book carefully if you think about buying it. I give it two out of five stars just because of the final two chapters.

Anyone who's been in network security long enough will tell you that the current state of products and `solutions' to security problems are woefully inadequate.

Firewalls, intrusion detection systems, content filters and anti-virus solutions are all reactive technologies, and as a result, they fail to address the primary cause of security vulnerabilities.


This root cause is bad software. Viruses, worms and hackers exploit vulnerabilities in the design and logic of software applications to compromise, destroy and otherwise take control of important information. Once you accept this fact, you'll realize that the only path to good security is to write better code.

`Exploiting Software - How to Break Code' is a book that fires up the hacker in me. It does not aim to teach you about the latest scanning tool, instead, it teaches you how to find and exploit vulnerabilities in systems. While many of the ideas in the book (such as the omnipresent buffer overflow) are not new, there is simply no literary comparison to the treatment given to them in this book.

Application security is one of the highest regarded and specialized technical services in the security industry, and thus, finding people (let alone books) that delve in-depth into the topic is rare and refreshing. The first day I used this book, I was on an application security project. The target application was a distributed database application running on SQL server with a web front-end.

I happened to have this book along with me, and while reading through it, the section on equivalent requests was something I hadn't tried - sure enough, 20 minutes later I had full control of the application and a very good impression of this book.

I particularly like the conceptual sections of this book, especially their idea of `attack patterns' - generic scenarios that often lead to compromise in systems. A thorough study of all these attack patterns will leave you a much better analyst than when you started out, and it definitely pays off when it comes to testing.

The book is also chock-a-block full of code, something that other books don't have the guts to do. Better yet, we're not talking about `hello world' stuff here, while reading the excellent chapter on root kits I finally realized that the device driver code I was trying out was way over my head. That's something you like to find, because it gives you something to learn.

The art of reverse engineering, disassembly, writing IDA-Pro plugins, black / white and grey-box techniques, advanced payload creation on multiple architectures - this book has it all. The only thing I can possibly say against it is that this it caters to a niche audience.

If you're not a coder or seriously into security however, large parts of the book may be inaccessible to you. However if you're a hacker, security tester or application developer and you don't own a copy of this book, you're not reaching your full potential.

A disturbing, subversive book. And I mean this in a positive sense. Hogland and McGraw explain the major ways in which software can be attacked.

They describe how reverse engineering can be done, even if all you have is binary code to work on. Given a disassembler and a decompiler, and these exist for all the major platforms, you can systematically apply white box, black box and grey box analysis to deconstruct a program.

They show how attacks can be done against servers, because nowadays on the net, servers are often tempting, fat targets. But from your standpoint, if you wish to defend against these attacks, you really need to be aware of the issues they raises. "Know the enemy". Plus, they also show how a server could attack, or be used to attack, unsuspecting clients that connect to it.

Of course, buffer overflows are the most commonly known source of attacks. Thus an entire chapter is devoted to this.

PHP users may not be thrilled to hear that it is fundamentally insecure. Its ease of learning and coding comes with this heavy price. Still, it is all the more reason that PHP users and sysadmins running web servers that use PHP, should be aware of the dangers in it.

The book is not a trivial read. The authors give detailed examples at the level of the x86 assembler. A strong background in this and in C/C++ will give you the greatest benefit when studying the book.

Target Audience
Software developers and network administrators who are responsible for or concerned with the security of the code they write or run.

Contents
This book covers software exploits and how they work.

The book is divided into the following chapters:

Software - The Root Of The Problem; Attack Patterns; Reverse Engineering And Program Understanding; Exploiting Server Software; Exploiting Client Software; Crafting (Malicious) Input; Buffer Overflow; Rootkits; References; Index

Review
Software security is foremost in the news today. You can't go a day without news on how another group has found and exploited some software flaw to create havoc on the internet. It seems that the software bugs are found faster than the developers can patch them. How can a software developer get ahead of the curve and write software that is more secure from the start? Get this book.

The authors start out with an overview of software and how code is open to bugs and exploits. By understanding the concepts of complexity, extensibility, and connectivity, you'll start to understand how easy it is for software to be "broke" by others to gain some sort of advantage or control over it. The rest of the book then goes into specific areas of attack and how they occur. There is an abundance of "attack patterns" that are highlighted throughout the chapters. These short sidebars will help you understand all the types of attacks that can (and will be) used against your systems. After you read and digest this information, you will be much better prepared to write code that is designed to be more secure from the initial design through implementation.

A question comes to mind quickly when reading the book... Isn't it dangerous to put all this hacking information in one place where anyone can access it? In my opinion, it's more dangerous to not have this data available. If a person wants to break your software or systems, they already know this stuff. In the case of software security, it's often the corporate developer who is at a distinct disadvantage as they are more concerned with getting their software to work in the first place. By having a single volume that explains the concepts of software exploitation in detail, we can all start to write secure software instead of writing patches to fix flawed code.

Conclusion
This book should be on the shelf of all software developers and administrators who are concerned about writing and administering secure software. And that should be all software developers and administrators! The information may be disturbing, but you need to understand it before others use the information against you.

Hoglund and McGraw is an amazing book. It's well written, comprehensive and full of detailed, up-to-date methodologies for messing with all kinds of code.

It's a shame the black hats can buy this book. However, since they can, every white hat should make a point of reading it to understand how subtle attacks can be and what kinds of tools are out there to help develop exploits.

Reading it will make you weep about the current state of operational code vulnerability!!!

The one major strength of this book, from a computer science viewpoint, is its emphasis on "attack patterns". This systemization of these issues really differentiates this book from many of its competitors (which tend to be either the latest 500 hacks or descriptions of standards). Put simply CS is the study of algorithms, and this book fits nicely into that tradition.

I read Exploiting Software (ES) last year but realized I hadn't reviewed it yet. Having read other books by these authors, like McGraw's Software Security and Hoglund's Rootkits, I realized ES was not as good as those newer books. At the time ES was published (2004) it continued to define the software exploitation genre begun in Building Secure Software. However, I don't think it's necessary to pay close attention to ES when newer books by McGraw and Hoglund are now available.

On the positive side, I appreciate three aspects of ES. First, I like the attention paid to attack patterns. This concept makes sense and should be used by other authors who want to describe a means to exploit a target. Second, I am impressed that ES features a whole chapter (5) on attacking client software. When ES was published, client-side attacks were just becoming popular. Discussing this problem shows great insights on the part of the authors. Third, several of the examples in ES are great case studies on exploiting software. When explained in sufficient detail they make for educational reading.

On the down side, I agree with several other reviewers that the book seems somewhat erratic. Attack patterns that are two sentences long are probably candidates for inclusion in a chart, not listed in the main text. I don't think the predictions found in ch 1 were necessary, and I think some of the criticism of detection methods in ch 6 border on the ignorant. I agree that perfect detection is impossible, but there are plenty of methods that work in the real world. They may not be real-time, but no intruder is perfectly stealthy in all aspects of an attack.

Regarding chapters 7 and 8, on buffer overflows and rootkits -- at 170 pages, those could almost have been their own book. The material doesn't seem to match the rest of the book, and it's obviously Hoglund's work. Add in a like-minded chapter on reverse engineering (3) at 74 pages and you definitely have a stand-alone book!

It's probably sufficient to read Building Secure Software, Software Security, and Rookits if you like the McGraw/Hoglund approach to attacking and defending software. Take a quick look at the attack pattern material to get a feel for that concept.