It's interesting to compare exploit tech from today to how simple things were back in '97. In '97, a complex exploit meant you couldn't have lowercase ASCII equivalents in your shellcode. Now, you scan the target for info leaks that will disclose stack cookies, and spray the heap to increase the odds that you'll hit your exploit in randomized memory, and forge stack frames that will return to mprotect or VirtualProtect, and and and.
So much of "security research" over the last 10 years has basically danced around a fundamental fact: if you lose control of the runtime memory of your program, you lose control of the whole program.
If you get lucky, your target won't bother with all these new-fangled protections and run on WinXP (no ASLR) and the only thing you'll have to contend with is non-executable stack. Our original exploit for Green Dam used a heap spray only to make writing it easier, and the underground exploit uses a really awful behavior of IE w.r.t. running .NET DLLs -- http://www.milw0rm.com/exploits/8938 . Other than that, there are no defenses to speak of.
Comments
It's interesting to compare exploit tech from today to how simple things were back in '97. In '97, a complex exploit meant you couldn't have lowercase ASCII equivalents in your shellcode. Now, you scan the target for info leaks that will disclose stack cookies, and spray the heap to increase the odds that you'll hit your exploit in randomized memory, and forge stack frames that will return to mprotect or VirtualProtect, and and and.
So much of "security research" over the last 10 years has basically danced around a fundamental fact: if you lose control of the runtime memory of your program, you lose control of the whole program.
If you get lucky, your target won't bother with all these new-fangled protections and run on WinXP (no ASLR) and the only thing you'll have to contend with is non-executable stack. Our original exploit for Green Dam used a heap spray only to make writing it easier, and the underground exploit uses a really awful behavior of IE w.r.t. running .NET DLLs -- http://www.milw0rm.com/exploits/8938 . Other than that, there are no defenses to speak of.
Even that really awful behavior of IE, that's a Black Hat '09 talk, isn't it?
Black Hat talks are not necessarily "new". Black Hat is not an academic security conference. The exploit was released months before BH09.
Well, that's sort of true. You don't necessarily have to keep track of the runtime memory as long as the buffer is large enough.
You could find the address of a JMP %ESP instruction in the victim OS (0x7C8369D8 in XP SP 2) and place it before a NOPsled.
A typical buffer overflow, for example:
[AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA][0x7C8369D8][NOP][shellcode]
You do, of course, need to make sure you don't have any \0 bytes in your shellcode, but that's always been the case.