When I first learned about heap spraying, I couldn't get the idea of whac-a-mole out of my head. In that classic carnival game, you hold a mallet and watch a variety of holes, waiting for the mole to pop out. The mole's appearance is random and very brief; you need to be quick to whack the mole. To me, finding the right address to direct the flow of execution is like trying to catch that mole. You have numerous spots to target and it's easy to miss the sweet spot at the right moment. Running with this analogy, imagine you could play whac-a-mole but with a mallet for every hole. You could then smack all of the mole's hiding spots in one whack. You'll end up delivering your payload (a whack of the mallet) to multiple locations in memory (mole holes) where the flow of execution doesn't go, but you'll hit the right one at the right moment.
Okay, maybe I got carried away with the mole analogy. The concept is called heap spraying because you're spraying the heap with your payload. The word spraying implies saturation, and that's what happens: you'll end up with many spots in memory where your payload is written and waiting, but you're only going to flow to one. The idea is that you've just increased the size of your target to can't-miss proportions:
We're going to write up some code that will spray the heap for us. We'll write a quick HTML page that will allocate space in the memory reserved for Internet Explorer. With some basic constructs in our code, we'll actually create chunks of data that consist of a large pad of NOPs followed by shellcode, and then spray this throughout the heap. When I word it this way, it sounds like we're going to break something for sure; in reality, all we're doing is allocating space and stuffing some bytes into it. Our shellcode is just junk until it's actually executed. The actual exploit is when we take control of execution and point it at a location in the heap where we'll land in an NOP sled.
For this exercise, I'm pulling out an old favorite vulnerability for studying overflows that can be exploited via social engineering techniques: CVE-2010-3552. This is a classic textbook stack-based overflow; a parameter isn't bounds-checked prior to writing to the buffer. In this specific case, we write a quick and dirty Java applet that kicks off the Java Network Launch Protocol (JNLP) while passing a value to a parameter called docbase. Overflowing this parameter will overwrite the return instruction pointer. Before we get down and dirty with the exploit, let's get some shellcode ready to go.