"Automatic Patch-Based Exploit Generation is Possible" - So say we all.

Posted by Gunter Ollmann on April 22, 2008 at 12:21 PM EDT.

Over the weekend I managed to read a new security paper titled “Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications” that goes in to some depth of how to automatically reverse engineer security patches and create (reliable?) exploits.

It’s an interesting paper, and I’d recommend that most security professionals read it (I wouldn’t worry too much about the math that’s in there if I was you – it’s more of a case of “math for math’s sake” than actually adding value to the paper).

I’ve been in two minds about commenting about the paper, but having read some of the nonsense editorials and blogs referring to the paper – “the sky is falling” – I figured it would probably be valuable to provide an “insider’s” perspective on automated exploit generation from patches.

My initial hesitation on posting was largely due to a case of “well, isn’t that nice, haven't people been doing this already for a couple of years” and, quite rightly, the authors imply that several times in their paper “best security practices dictate that we conservatively estimate the power of an attacker, our results imply that in security critical scenarios automatic patch-based exploit generation should be considered practical.” – better late than never.

Brass Tacks

Getting down to brass tacks – yes, it is technically possible to automatically generate exploit material for a fixed vulnerability using knowledge of the differences between the patched and unpatched software – no surprise there.

While I’m not aware of any commercial tools that automatically do this today, there certainly is a historical market for tools, plug-ins and add-ons that simplify that task for security researchers and reverse engineers to do this very thing. Several of these tools have the capabilities to generate the pseudo code necessary to craft an exploit for the particular OS flavor they are running (“reliability” is open for debate though).

I suppose the question is whether it’s to the attackers advantage to use a tool that automatically creates exploit code from newly released patches? If it was to work reliably, then the answer would be “of course!” We have already observed the commercial incentive behind attackers slipping in and out in the midst of a shrinking patching window. Looking at the value of exploit code traded within the darker side of the Internet, we’ve seen its exponential value curve become steeper – prices increasing for exploits released within hours of patch availability, and prices hitting rock bottom for exploits released a day or two later - pricing which has probably been driven to a large extent by the use of x-morphic attack engines in drive-by-download attacks.

I’d have to wonder though whether it’s to the commercial attackers advantage to invest in creating a robust auto-exploit generating engine, are the economics right? As the paper points out, not all vulnerabilities are created equal, and various levels of code obfuscation techniques can probably make it pretty darn difficult to auto-gen an exploit (and not hang/crash the exploit generator). So, to create a reliable tool is going to take a fair amount of effort (and more effort to maintain the tool going forward as vendors rework their patching response) from some reasonably skilled reverse engineers. Meanwhile, those very same reverse engineers can churn out reliable exploits at a fast enough rate to keep their employers happy – and still be able to manually bypass most reconfigurations the vendors may implement.

That said, we can probably look forward to someone somewhere releasing a public beta for exploit auto-generation fairly soon – most likely someone trying to prove their skills, and unlikely to be involved in the commercial attack scene (yet?). If I had to place money on where we’ll see the first “proper” auto-gen exploit tool, it’ll probably be from a Metasploit contributor.

Fame & Fortune

Does fame & fortune await the developer of a “reliable” auto-exploit-generator? Fame/infamy probably does – I’m not so sure about the fortune part unless they can set up a business and commercialize it (even then, it’ll probably be cannibalized by the bad guys and incorporated into their commercial offerings for one percent of the cost).

So, going beyond the notoriety of building a reliable auto-exploit-generator, is it actually likely to be useful in attacking and claiming victims through missing patches? Until the opportunity window slides firmly shut on application patching – yes, probably. I say “probably” because I suspect that future automated tools will also use stock shellcode and exploit techniques – which will subsequently be easier to stop using protocol-based intrusion prevention systems.

But let’s be clear, the probability that an auto-exploit-generator (working off newly released patches) actually changing the threat landscape is pretty small. For one thing, the dangerous vulnerabilities lying in contemporary operating systems tend to be real pigs to exploit reliably and require a considerable amount of elbow-grease to develop and get right, and they’re not really getting any easier. Yes, vulnerabilities like the one lying at the root cause of Slammer are fairly simple, but the industry has moved on since then – lessons have been learned – and those types of vulnerability are much rarer (but not impossible, since there are still humans doign the coding).

In a battle between man and machine, I know where I’d place my money. I’ll meet your auto-exploit-generator and raise you a Mark Dowd… although some may argue that thats cheating since Mark may be a machine sent back in time.