Infosec Writers

Exploiting Software: How to Break Code, reviewed by Thomas Duff; March 6, 2004; Portland Domino/Notes User Group

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.

Original Review