What’s still exploitable?

OK, just throwing this out, hoping for some interesting comments - if you have NX, ASLR, and SafeSEH, what's still exploitable?

Please note I'm absolutely, positively NOT NOT NOT saying that stuff compiled with all this is unbreakable or any such silliness. If you mess up bad enough, or the attacker is clever enough, you're in trouble, but it does start to get to be a challenge.

I'll start out with an obvious one - data changing attacks leveraging return into libc are still available - if there's a mutable buffer that holds the path to a .DLL, and I can change the contents of that path prior to having LoadLibrary called, game over. Of course, finding the buffer gets to be just a little more fun with ASLR.

 Now for bonus points, assume 64-bit - now what?

[ follow-up ]

I should have been more specific, like one of the comments said - there's whole classes of things that are still exploitable - XSS, SQL injection, session problems, all sorts of stuff. Plenty of work for us security people for a long time to come.

What I'm specifically asking about is taking control of an application by causing it to run arbitrary code.

I'll give another example of something exploitable - quite a while back, NFS had an integer truncation problem where 32-bits on the wire got truncated to a 16 bit uid, the check whether someone was root happened on the 32-bit value, but access was granted based on the 16-bit value. Gave remote root file system access to a lot of people. Interesting attack, and one that sparked some of my early interest in integer mayhem. There's no arbitrary code involved.

What I'm really after, though, is let's say there's a crash, and you're trying to figure out what's exploitable. On one hand, assume say XP, older hardware, only defense might be SafeSEH and /GS. Fair bit of stuff gets past those countermeasures. Now add ASLR and NX - what gets past all that?


Comments (2)

  1. Ryan Russell says:

    Be more specific, please. I assume you mean within the programming mistakes that allow for overflows, for example. Because there are still vast categories of other kinds of mistakes that allow for compromise. I’ll just throw out XSS as one big hairy example.

  2. Type safety bugs in the .NET JIT are still exploitable. I found such a bug in December (see the link) and none of the mentioned safety measures make any difference:

    NX: the JIT uses writeable executable memory, finding it is trivial.

    ASLR: if you’re running .NET code that has full memory access, searching all 256 locations is trivial.

Skip to main content