Hacker News Reader

Comment by jdp23 | Hacker News Reader

Much of the early work on buffer overrun exploitation was published in Phrack. The article Brandon Baker and I did for IEEE Security and Privacy had a sidebar on "Nontraditional literature on buffer overruns" that's got some greatest hits like AlephOne’s Smashing the Stack for Fun and Profit from 1996 [1] and The Advanced return-into-lib(c) Exploits from 2001 [2]. Over the years, a surprising number of people have told me that this was their favorite part of the article!

[1] https://www.phrack.org/show.php?p=49&a=14

[2] https://www.phrack.org/show.php?p=58&a=4

View on HN

"Smashing the Stack for Fun and Profit" is the reason why I work with computers nowadays. I don't even work in security - this is the article that made me realise computers are full of wonder.

That article brought the knowledge to the security scenes, but pirates cracking video games have been exploiting that for a while too. Those familiar with Morris internet worm also knew about it. This as I can really was the first place that broke it down where you could learn it yourself without a guide. It's also one of my favorite as I knew about it, but didn't know how to personally craft one till I read that.

That's how I remember it too - demystifying an arcane technique.

I remember buffer overflow bugs in the operating systems in the 1970's. They go back a loooong way, and programmers are slow learners :-)

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.

Right. Nate Lawson has some thoughts on why at https://rdist.root.org/2010/05/03/why-buffer-overflow-exploi... and https://rdist.root.org/2010/05/05/why-buffer-overflow-exploi...

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.

Oh if only there were an alternative C-like language that could guarantee memory safety!

That's a great idea! I should get right on that!

Is there a today equivalent ?

PoC||GTFO

https://www.alchemistowl.org/pocorgtfo/

Personally for me PoC||GTFO fills up the void. They have some good articles and explaining in very friendly way.

[0] https://www.alchemistowl.org/pocorgtfo/

Indeed! Reading those issues, for me, is a stream of shock and awe but always learning because the contributors generally give sufficient instructions to perform/confirm their achievements yourself.

Example ... about halfway through Issue 0x02 it is casually mentioned, "You will find by running ‘qemu-system-i386 -fda pocorgtfo02.pdf’ that the PDF file you are reading is also a bootable disk image." o_O !

PoC || GTFO

All 3 of us said the same thing at the same time :)

Reply on news.ycombinator.com