The Future of Software Vulnerability Exploitation

Print Friendly, PDF & Email

Next week I will be speaking at Virus Bulletin 2014 about how every month, attackers successfully compromise hundreds of thousands of computers from just tens of legitimate, top-ranked websites. Such campaigns are orchestrated via drive-by downloads, which target vulnerabilities in the web browser or its plugins. Software vulnerability exploitation continues to be the bane of securing an organization's systems and networks because even security conscious users who follow best practices remain vulnerable. This post briefly considers advances in compiler and OS-level protections that have substantially complicated (and may one day eliminate) the successful exploitation of such vulnerabilities.

The execution of arbitrary, attacker-decided code begins with the exploitation of a software vulnerability that corresponds to one of a small number of exploit classes (i.e., stack buffer overflows, heap overflows, use-after-free exploits). New classes of software exploitation or defense mitigation are rare — so rare that vendors like Microsoft will pay $100,000 or more for their discovery. Moreover, because there are a small number of exploit classes, compiler and OS software vendors have developed numerous defenses that must be bypassed (i.e., via the discovery and exploitation of separate vulnerabilities). Thus, an exploit that targets an arbitrary code execution vulnerability in a modern, popular software instance (i.e., Internet Explorer) is but one component that must be combined with others to pull off a successful attack.

Finding additional vulnerabilities to create a working attack sequence may sound like a linear increase in the amount of work for an attacker, but there is actually significant asymmetry (that favors the defender) at play. Consider the canonical stack buffer overflow attack: originally, all an attacker needed to do was overwrite the return address so that their shellcode was executed when a function returned. Now, an attacker must:

1) Determine a bypass for the results of overwriting a stack canary (e.g., by targeting an exception handler address on the stack instead);
2) Determine a bypass for a non-executable stack (e.g., by reusing parts of the original program to create a fake stack frame);
3) Potentially identify a separate vulnerability that bypasses SafeSEH or SEHOP (e.g., by finding some way to fake exception handler integrity);
4) Identify a separate vulnerability that bypasses ASLR (i.e., that leaks API and shellcode address information);
5) Identify a separate vulnerability that allows the shellcode to escape from a sandbox (which when implemented via a separate arbitrary code execution vulnerability, requires identification of separate bypasses that allow equivalents of previously mentioned steps to be repeated).

As implied by the above set of steps, successful utilization of a stack buffer overflow in a modern instance of software is now so difficult to pull off that attackers have moved on to easier targets. For such a strategy to remain feasible, an easier target must exist, and that may not be the case forever. Given the small number of exploit classes, the adoption of exploit mitigation techniques by modern software, and that innovations like ASLR increase exploit resistance across multiple scenarios, there may come a time when every vulnerability requires herculean effort to successfully weaponize. For the countless security professionals who must deal with the direct and indirect consequences of software vulnerability exploitation, that day cannot come soon enough.

Thanks to Artem Dinaburg of Trail of Bits for inspiration and advice associated with the creation of this post.

Scroll to top
Tweet
Share
Share