19

I was wondering if anyone could give me some clues on how "leaking pointers" to bypass DEP/ASLR work. I read here:

The only way to reliably bypass DEP and ASLR is through an pointer leak. This is a situation where a value on the stack, at a reliable location, might be used to locate a usable function pointer or ROP gadget. Once this is done, it is sometimes possible to create a payload that reliably bypasses both protection mechanisms.

how this is accomplished is kind of a mystery to me. I have a buffer overflow.. so I can overwrite till EIP and stack contents.. I have a reliable function pointer or code pointer in the stack, and I know where this is stored.. also if I know this location.. how do I put this address in EIP? I can't control the execution stream if I can't change EIP to that reliable location

Community
  • 1
John Smith
  • 509
  • 1
  • 5
  • 8

2 Answers2

15

"Leaky Pointers", more commonly known as "Dangling Pointers", is useful to create an attack chain to bypass a layered security system.

The idea behind DEP is that you are making regions of memory non-executable, such that shellcode in this area cannot be executed. DEP alone is really easy to bypass, you can just ret-to-lib, and call any function you would like, system() is a favorite.

However, under Windows, ASLR enabled libraries will have a randomized memory space, so the attacker won't know the memory address of the system() function, and therefore cannot call it. The idea behind ASLR is that it doesn't matter if you can control the EIP if you don't know where to jump to.

Being able to read the location of a region of randomized memory undermines the protection of ASLR, because now you have a reliable jump location. This can be accomplished though a wide variety of methods. Using a buffer overflow to simply overwrite the null terminator and read past the end of an array has been used in pwn2own against IE. But really the most common technique is using a Dangling Pointer which can be used to read/write or even execute a valid memory location despite ASLR.

Even with ASLR, not every memory location is randomized. In fact the executable binary has a predictable layout, so you can use the executable against itself in a ROP Chain. However sometimes it's difficult to find useful ROP gadgets, especially if the target binary is very small. If you are unable to build a useful ROP Chain, then a memory disclosure vulnerability, such as a dangling pointer, is a great method of attack. It's important to note that ASLR only randomizes the location of the page (the first few bytes of the memory address.) If you can populate a region within this page with your shellcode then it may be possible to accurately execute your shellcode by using the leaked memory address as a base and then hopefully your shellcode is at some offset of this random location.

Using chains of memory manipulation vulnerabilities is unusually only possible inside a scripting environment, such as JavaScript.

waded
  • 3
  • 2
rook
  • 47,004
  • 10
  • 94
  • 182
  • Care to expand this to include a quick explanation of how it's possible to leverage such a dangling pointer when you can't build reliable ROP chains due to ASLR? – Polynomial Oct 22 '12 at 19:54
  • @Polynomial updated, hopefully that makes sense. – rook Oct 22 '12 at 20:03
  • Yep, that's a nice summary. Might be nice to actually mention a nopsled here though, since it's somewhat relevant. – Polynomial Oct 22 '12 at 20:11
  • I got the pwn2own one, nice. But I still can't figure out how to use these "dangling pointers".. how am I supposed to "read" the address where that pointer points to know the offset from the base and build my rop gadgets? – John Smith Oct 22 '12 at 20:54
  • @John Smith ROP and dangling pointers are two different tools that can be used to gather, but not always. Being able to read a randomly generated memory address means its no longer a secret and now you know where to jump to. Its really that simple. – rook Oct 22 '12 at 21:54
  • I agree with you, but the "being able to read" part is a bit mysterious to me.. let's suppose that I overflowed a buffer, that I know that there's a reliable pointer location on the stack... how do I read it or even reach it with a RET? I don't know any RET address nor can I rely on one because of ASLR – John Smith Oct 22 '12 at 23:33
  • 1
    @John Smith Not all dangling pointers are for reading... Usually when an attacker both can read memory using a dangling pointer and then use a buffer overflow you are in a scripting environment, like javascript and you are exploiting some function call, library or API exposed to the scripting environment. – rook Oct 23 '12 at 00:46
5

ASLR involves randomizing the location of objects in memory. For instance, the heap might be moved to a random offset in memory.

If you somehow manage to learn the address of an object in the heap, then you've gained a lot of information about the location of the heap in memory. This may be enough to enable you to predict the location of other objects in the heap. At that point, ASLR's randomization becomes useless. So, information disclosure vulnerabilities that reveal the value of a pointer (its address) can potentially be used to subvert ASLR.

How can the address of a pointer leak? One way is through a format string vulnerability. Suppose your does this something like this:

printf(msg);

where msg is an attacker-controlled message, and where the attacker can read stdout. Then the attacker can specify that message should be the string "%d", and this will reveal the value of some random data on the stack, which might well be a valid pointer. (Why? Because printf() thinks you passed another argument and goes looking on the stack to find and print the value of that additional argument. It has no idea that you didn't actually pass another argument and it is actually trawling through unrelated memory.)

There are other ways that this kind of information can be leaked, but when it can, you can often bypass ASLR. Once you can bypass ASLR, you can then use standard techniques to exploit a buffer overrun vulnerability. So, these kinds of information disclosure vulnerabilities are not a good thing to have in your application.

D.W.
  • 98,860
  • 33
  • 271
  • 588