A Vulnerability Renaissance

After a conversation with a friend of mine it is my opinion that the security industry is evolving, but like many other technology industries will repeat its own past in due time. In the early 2000's new techniques for exploiting the traditional vulnerability classes (stack, heap, race, format) were coming out at a rate of every few months. Every application written in C/C++ has since undergone intense scrutiny to eradicate all of these vulnerabilities. Thus we dont see a new stack/heap/race/format advisory everyday like we used to 3 years ago. The ones we do see are complex and obscure enough to evade the common code auditor with less skill. As an industry we havent seen a new bug class emerge for quite some time, the latest being the explosion of XSS techniques. This in my opinion is partly due to the nature of attacking software at such a high level, there are just so many more directions to poke in.

How long before we undergo a sort of vulnerability renaissance and new bug classes emerge at lower levels? Will we once again see daily advisories for apache/bind/sendmail/ssh? For those who say its impossible due to the amount of code auditing performed on these applications all I can say is look at the past 4-5 years of bugtraq/full-disclosure postings. It took many years to find bug classes in languages that are in some cases older then the researcher who found them.

As a side note I find it quite interesting how just one new bug class that can be easily exploited in C/C++ applications will probably fuel another 5-10 years of security industry revenues. This is because a large percentage of deployed protections will need to be re-evaluated. This sort of possibility should be a wakeup call to anyone working in security, that all vulnerabilities are never known and threat/risk models can change overnight with a few lines of code. I personally hope we do witness this renaissance soon. Not only because that means it was discovered by someone responsible with enough brains to make us all aware but also because history has taught us it inevitable and I would like to see it sooner rather then later (this makes the classic assumption that there is a possibility the bad guys already possess this knowledge and are using it to their advantage). This possibility should further fuel our progression towards pro-active security defenses, as reactive systems have shown us they cant protect you from tomorrows bugs. Memory protection techniques (ASLR, NX, etc...) are a step in the right direction. But we dont know what tommorrow will bring. And thats my security rant for the day.

The Art of Software Security Assessment Review

The Art Of Software Security Assessment arrived yesterday and I have been furiously taking it in. Im sure many other people are going to review this book so I will keep it short. This book rocks for a couple of reasons.

#1 The authors. Its the same reason 'Shellcoders Handbook' was such a success. You need people with real world experience writing this kind of stuff.

#2 The level of detail. This book goes very deep. Especially the chapter on C language vulnerabilities. Mark Dowd was nice enough to release this chapter last month before the books release. I read that chapter from PDF last month, it covered signed/unsigned variable issues better then any book I have ever read. Most books go about as deep as strcpy(). Its the obscure details of specific languages and operating systems that make vulnerability hunting so much fun.

#3. Chapter 16 is great. It covers attacking network application protocols. Sometimes its really hard to explain a protocols standard and then relate it to attacking its implementation. This time they got it right. READ THIS CHAPTER.

Normally a book that covers everything from specific language details to attacking networking protocols is spread too thin. But these massive 1200 pages cover it perfectly. Now when someone asks me how to get started in my line of work I have an answer. 'Learn an OS ins/outs, learn a couple programming languages and read this book cover to cover'. I wont be putting this book on the shelf for a long time.