When trying to exploit a memory corruption bug on a reasonably hardened target, there’s a tradeoff around where to invest time. Would it be most efficient to try and find the most powerful, most readily exploitable bug possible? Or would it be better to stick with the first decent bug you find and invest time instead in developing a really great exploit technique that will make up for the bug’s lack of power?

This isn’t a tradeoff that needs to be faced on soft targets with no mitigations since almost any memory corruption bug can be straightforwardly turned into a full exploit using readily-available techniques. For example, you might find a stack buffer overflow that smashes the return address on some IOT device with an executable heap and no ASLR. There’s a plethora of blog posts and CTF writeups on how to exploit this type of bug: spray some shellcode in the heap and smash the return address to point to it. Sure, it might take a good deal of effort to adapt the technique used in a blog post to work on your exact target, but the difficulty is not in the technique itself.

Meanwhile, on hardened targets, you’ll probably have to think a lot more about techniques. If the same stack buffer overflow from before existed on a system with ASLR and W^X, you might not be able to usefully clobber the return address without a separate stack infoleak first to disclose the stack canary value and the address of some executable code to launch a ROP payload; or on a system with shadow stacks or Pointer Authentication the return address might not a useful target for the bug at all. Now there’s a question: should you invest in finding an exploit technique that makes this bug work, or should you instead abandon this bug and invest in finding a better one?

The obvious tradeoff here is that the weaker the bug, the more powerful the technique you need to transform that bug into a useful primitive, and vice versa. Of course, exploit techniques aren’t fully fungible between different vulnerabilities like this: they don’t plug into bugs like Legos. But the intuition that there’s a tension here matches my hands-on experience writing exploits.

When I have a crummy memory corruption bug that only perturbs the system state a little bit, like a one-shot increment at a fixed offset out-of-bounds of a short-lived heap allocation, then it usually takes a good amount of effort to find a particularly “powerful” victim object to corrupt in order to construct a reasonable exploit path. And interestingly, I’ll often find that that object is a useful victim for many other bugs of equal or stronger power, too, suggesting that technique power is related to technique flexibility. This matters because, on a well-hardened system, the availability of exploit techniques can become more of a funnel point in defining the shape of exploit flows than the availability of vulnerabilities.

All of this points to an interesting duality between vulnerabilities and exploit techniques. From a defensive perspective, vulnerabilities are treated as flaws while techniques are often seen as just leveraging how the system works. But that distinction disappears from the offensive perspective. An attacker can find a vulnerability and then search for an exploit technique that will work for that bug (that’s usually what I do). But they could also find a good exploit technique that avoids the mitigations and then search for a vulnerability that would chain well with it.

It sometimes seems to me like defensive security teams for hardened systems might over-focus on bugs and under-focus on techniques. I think a lot of this comes from a focus on attack surfaces, and to be fair, focusing on attack surfaces is usually the right lens. I have no clue how to identify the right balance to strike between vulnerability- vs. technique-oriented research for any particular system. The only real advice I can give to defensive vulnerability research teams is the following: First, the amount of effort focused on exploit techniques should probably scale with how hardened the system you’re looking at is. Second, the effort spent looking at techniques is valuable not just to eliminate whichever ones are particularly attractive, but also as a guide to search for vulnerabilities that might be paired with those techniques that cannot be mitigated.