software design

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.

I suppose any book about how to hack software is going to be controversial, but think about it, unless you know what the holes in software are how are you supposed to fix them. Using the right framework isn't enough because every framework is going to have security issues. You actually need to understand what is going on and this is the true value of the book.

The coverage is not just at the bits and bytes level. The authors cover the theory of each exploit and then dig down into what happens at the processor and virtual machine level to complete the exploit. The problem that I find with the book is that it doesn't complete the cycle by bringing the reader back through the process to identify a robust fix for the hole.

I'm still giving the book four stars though because it does present the vulnerabilities in a qualified way, which makes for interesting read and for cool thought puzzles in how to fix the security problem, or to extend the attack method to other vulnerable areas.

For anyone tasked with securing a complex application, especially one that is connected to, or serving on, the Internet, you should read this book. Both to understand the scope of the security problems and to see how you can fix the vulnerabilities in your own code.

To be useful, software must respond to events in a predictable manner. The results can then be used as a window to the interior workings of the code, revealing some of the mechanisms of operations, which may be used to find ways to make it fail in a dangerous way. To some, the window is as clear as a six inch thick pane of lead, but to those with a high level of understanding it can be clear, or at the very least serve as a keyhole. This is an allusion to the old detective stories where someone looks through the keyhole to see what is behind the door. For these reasons, no software that interacts with humans can ever be considered completely secure, and human error in the development of the software can leave the equivalent of keyholes throughout the code.
This book is an explanation of many of the most frequently used attack strategies used by malicious entities to find security flaws in code and exploit them. Chapter two is a list of the most common patterns used in attacking code, and all types of programs, from applications to compilers to network software are examined. In chapter three, the fundamental steps of reverse engineering source code starting with the executable are described in detail. I have had students who work in industry who have argued vehemently that it is not possible to obtain source code from executable. I knew it was possible, but until I read this chapter, I had no idea it was so easy. If you are releasing your programs as executables created directly from the source code, the examples here will very quickly make you reconsider. Without a doubt, you will be convinced that you should perform some form of obfuscation of the source before compiling or perform some type of encryption.
Chapters four and five are how to exploit server and client software respectively. From the perspective of the server, every input should be considered suspect, and you cannot assume that any scripting code embedded in the file was run at the client. In many cases, assumptions like this can create problems. People embed hidden fields or Javascript in HTML files and assume that the inputs are then clean, forgetting that all such code is visible to a potential attacker. This is actually worse than nothing, because an attacker can look at the features and get a good idea about what it is you are afraid of receiving. Each chapter has a list of specific strategies that are used in attacks.
In chapter six, you get a very brutal lesson in the wisdom of filtering input and never forgetting that characters come in more than one form. Characters such as the slash and backslash are used in representing directory structures. Some code will filter them out, but fail to catch instances where they are sent in their numeric ASCII or Unicode form. One of the classic attempts to beat the filtering is to try the sequence "\/", in the hopes that the first will be considered an escape character, so that the slash can be embedded in a string. If that happens, then the slash could be used in a pathname. Many other possibilities exist to send code that is clearly malicious, but only if it is interpreted the proper way.
Chapter six is a complete tour of the most common security weakness found in software, the buffer overflow. It is the simplest problem to understand and one of the most difficult to remove. Every C programmer has had to find and repair a bug due to an off-by-one error, or some other overflow. And yet, despite all this experience, buffer overflows still are prevalent in commercial code. Most of the obvious ones have been removed, so only the very subtle ones remain. Some of these are very hard and very, very subtle. I was amazed in reading the section on format string vulnerabilities. While this bug has largely been repaired, the fact that something as apparently trivial as a format field specifier can be a security problem was a real eye opener.
The last chapter was an explanation of rootkits, the software that controls every aspect of the machine. It was also without question the scariest of all the chapters, because in this case, the malicious code could reside in the BIOS, and be largely immune to virus scanning tools. For the first time, we are talking about hardware viruses that can be spread from machine to machine. Some of the attacks are also very simple. Since flash memory can only be rewritten a certain number of times, a virus that simply rewrites it many times can render it worthless.
It has been some time since I have written commercial code, most of what I have written recently has been for training purposes. After reading this book, I have begun a crash program of writing code that demonstrates security flaws and have used it in my courses. If I ever go back to managing a coding team, no one will write a line of code before we cover this book in the finest possible detail. Without question it will be on my list of the best books of the year 2004.

Published in the online Journal of Object Technology, reprinted with permission.