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.
In one of my freshman CS courses, one of our last assignments was to read this paper (as well as a more approachable tutorial written by our TAs) and carry this out on a toy architecture (LC3) that we had been working with for the whole course. It was probably the most interesting assignment we had that semester.
Funny how the first example contains a subtle bug, the string termination is never done, if the stack wasn't zeroed prior to running that program, you may not only overflow 'buffer' on purpose, you may overflow it a lot further than you'd think by just reading the code.
I remember reading this paper as an undergrad at Rutgers. We had to do a stack smashing project based on this with different stack protection methods (canaries/ASLR)
This was probably one of the most important things I learned in school.
I remember reading this and finding an error in one of the examples.
In addition to learning about the stack, I also realized that superheroes are human, too. <3
There was a frantic race to get the first overflow out after 8lgm capped off their run of zero-days with an announcement of a Sendmail 8.6.12 remote that relied on a syslog() overflow (yes, in 1995, syslog(3) had an overflow). I was sitting next to Pieter when he wrote part of the tutorial you linked to. I was pretty young (maybe 19?) but even so, it was a pretty electric time to be involved in security.
[+] [-] tptacek|16 years ago|reply
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.
[+] [-] swolchok|16 years ago|reply
[+] [-] Zarathu|16 years ago|reply
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.
[+] [-] mahmud|16 years ago|reply
112,605 documents found
http://citeseerx.ist.psu.edu/search?q=Smashing+The+Stack+For...
[+] [-] lg|16 years ago|reply
[+] [-] alecco|16 years ago|reply
[+] [-] scythe|16 years ago|reply
[+] [-] Oompa|16 years ago|reply
[+] [-] jacquesm|16 years ago|reply
large_string[255] = 0;
Would solve that.
[+] [-] wclax04|16 years ago|reply
This was probably one of the most important things I learned in school.
[+] [-] haupt|16 years ago|reply
[+] [-] MtL|16 years ago|reply
[+] [-] sown|16 years ago|reply
[+] [-] petsos|16 years ago|reply
[+] [-] leif|16 years ago|reply
[+] [-] omouse|16 years ago|reply
[+] [-] tptacek|16 years ago|reply
[+] [-] ecq|16 years ago|reply
Another tutorial pre-dates this by ~1 year. It was written by mudge.
http://biblio.l0t3k.net/b0f/en/howto_write_buffer.txt
[+] [-] tptacek|16 years ago|reply
http://seclists.org/bugtraq/1995/Dec/2
(My business partner co-authored it).
The first shellcode-style buffer overflow (besides the rtm worm) was Thomas Lopatic's HPUX HTTPd vulnerability from a few months earlier:
http://seclists.org/bugtraq/1995/Feb/109
There was a frantic race to get the first overflow out after 8lgm capped off their run of zero-days with an announcement of a Sendmail 8.6.12 remote that relied on a syslog() overflow (yes, in 1995, syslog(3) had an overflow). I was sitting next to Pieter when he wrote part of the tutorial you linked to. I was pretty young (maybe 19?) but even so, it was a pretty electric time to be involved in security.
[+] [-] sp332|16 years ago|reply
[+] [-] c00p3r|16 years ago|reply