Buffer overflows are common, but control flow injection through memory corruption has a weird little history. You don't see them in the record until RTM's worm (HN connection: pg and rtm were best friends at the time, and pg was a bit player in writeups about the worm). Then: nothing, for 7 years, until Thomas Lopatic publishes the HPUX httpd overflow in '95. It's not like the intervening 7 years were quiet ones in computer security; '88-'95 was more or less the golden age of computer hacking.
The overflow bugs I knew about were used to crash the operating system. They were submitted to DEC who presumably fixed them. As far as I know, using them to inject code hadn't occurred to anyone yet.
Right, there is definitely a longer history of memory corruption vulnerabilities; for instance, there's an old rdist vulnerability that exploits an overflow to overwrite a global variable. What's interesting to me is the initial idea of control flow injection, and how long it took that idea to percolate through to exploit developers.
I was doing software security semi-professionally before the 8lgm Sendmail 8.6.12 vulnerability that set off the modern buffer overflow craze, and worked with a bunch of people frantically reconstructing that exploit (which wasn't published) --- the authors of the first x86 stack overflow vulnerability included my future business partner at Matasano, Dave Goldsmith.
It was light night and day! Before overflows, there was a whole variety of different "kinds" of exploits (you got some command injection with metacharacters, for instance with SunRPC services calling popen and system, but you also got "overwrite a file" or "leak a file" or things like that). Afterwards, it was just: every machine on the Internet had remote code execution via overflows.
It used to be feasible to calibrate an stack exploit for a remote service, for which you didn't even have source, in an hour or two of tinkering. It's crazy to think of how far things have gone since then.
