In A Bug Hunter's Diary, Tobias Klein provides a peek inside the work of a professional bug hunter and shares valuable information on the tools of the trade. Readers get to follow along as he identifies bugs and works through the process of locating, exploiting, documenting, and reporting these bugs.
Real-world bug hunting
I was surprised the book was just over 200 pages, but the page count is rather low because Klein doesn't try to tailor the book to all audiences — he assumes the reader has more than a beginner's level of knowledge and skill in the subject. It's refreshing that the author doesn't bog you down with basic material that can easily be found elsewhere.
This book isn't a tutorial on application security, but instead focuses on real-world examples. There is one example per chapter, followed by appendices with additional information on bug hunting, debugging tools, and mitigation techniques. The examples range from operating system kernel bugs to a VLC media player problems and Web issues with the WebEx ActiveX control. The author begins with a description of the bug and how he identified and found it, which he calls vulnerability discovery. This continues with a demonstration of the bug and how it is exploited.
The bug hunting process is something of a black art, and the entire process is like solving a puzzle. The details of the process can be a bit overwhelming, as Klein goes all the way down to assembly language in some examples, but don't let that scare you away. The final step is remediation, which covers how the bug was communicated to the software vendor — this can go through a broker or via direct connection to the company as was the case with Apple and a bug found in an early version of the Apple iOS. A Lessons Learned section provides valuable information on security vulnerabilities and the process of locating these bugs.
At the end of each chapter, there is an Addendum section that details information on communication of the bug, if the bug was addressed by the vendor, and a timeline. The timeline is one of my favorite parts of each chapter because it shows when the bug was found and when it is addressed and communicated. While it is a small sample size, these timelines show large corporations are slower to respond to bugs than open source applications/communities.
The bug hunting community
We've all read stories about various browser bugs, but I had never given much thought to the community of bug hunters who find these bugs and make money on them. This book reveals this sort of underground community; the author explains how a bug may be revealed (contact vendor, communicate to the world, sell to a broker, etc.). The part about selling to a broker surprised me, but it seems like something I should have known. As an example, the author sold the bug and fix for the WebEx ActiveX control vulnerability to a vulnerability broker and let the broker handle working with the vendor. This made me wonder how these brokers work and how much they are paid by software vendors.
Even though I don't think I'll ever be a professional bug hunter, the numerous tools discussed in the book are great additions to my development toolbox. Several examples include COMRaider for working with COM objects, WinDbg for debugging on Windows, and Process Explorer for getting more details on resources used by running processes. The book also includes references to websites that offer valuable information on security concepts.
A good read
While I am not a hard core C or assembly language programmer, I loved the book; I felt like I was watching over the author's shoulder as he tracked down software bugs. This is a valuable book for a wide range of IT folks, including programmers, bug hunters, and support personnel. I think A Bug Hunter's Diary would be a great addition to your bookshelf.
What books do you find helpful in your daily work? Share you favorites with the community.
Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a production environment on a daily basis.