Uncertainty And The Cost Of Failed Exploitation

A lot of what people have realized in computer security is that keeping attackers at bay is largely about making targets too expensive. By adding a sandbox we ensure an attacker needs to either monetize the sandbox or make use of an exploit that bypasses it – that second exploit is going to be costly.

Sandboxing is one of the most popular and effective methods for raising the cost but it’s by no means perfect.

I think another cost we should focus on is the cost of failed exploitation. While sandboxing raises the cost of a monetizing the system an attacker can still come up with a reliable way of breaking through it, dispatch the exploit, and make their money.

What I would like to see is a method of raising the cost of exploitation through uncertainty. ASLR randomizes a processes address space and when implemented properly an attacker is often forced to use less reliable means of attack, bruteforcing through an address space for example or repeatedly forking and attempting the exploit. With multiprocess browsers this type of attack seems much more likely to occur in the future.

Attackers need reliability because if they send their brand new 0day out there and it’s not working, or doesn’t work reliably, they’re making way less money and the company responsible for that vulnerable software is going to patch it up before it can be monetized properly. As soon as they release their 0day it’s out there for the world to discover and defend against – they need it to work quickly, they typically have 24-72 hours before a patch is released.

If an attacker has a 1 in 8 chance of successfully exploiting the target but they can constantly fork processes (their attempt to exploit crashes it, the process restarts automatically – the attacker isn’t doing it, just to clarify) and attempt over and over they’ll eventually get a successful hit. The key point here is that the time it takes for this unreliable attack to bruteforce its way to success is far lower than the time it takes for either an administrator to notice the attack or a patch for the vulnerability to come about.

Bruteforce Exploit Prevention, which is built into Grsecurity, is the type of mitigation that takes advantage of unreliable attacks. By detecting the attack, crashing the UID responsible, and waiting before reloading those vulnerable services Grsecurity makes  unreliable attacks far too costly. An attacker who attempts to exploit a service will have released their 0day and gained nothing, and all the would-be victim has to do is report the attack and their 0day will soon be patched. Attackers need to hit fast and hard and across the spectrum or they start pulling in way less and the value of their 0day (in terms of sales) goes way down.

These types of techniques are going to become much more important as systems implement proper ASLR (Windows 8 has made serious improvements) because attackers will have to rely on other methods. Multiprocess browsers are also the type of attack surface where an unreliable exploit can be bruteforced over and over again and as more browsers move to this model we will likely see these attacks used.