How To Conduct Your Very Own Buffer Overflow

Adam writes "If you've ever wanted to create your own buffer overflow or just to see how one works, check out this tutorial. The article talks about how a buffer overflow works and gives a guided example through an exploit to help you on your way. Definitely worth checking out." From the article: "Every now and again we all hear about an exploit that takes place thanks to a buffer overflow, but what is a buffer overflow? By definition it is when a program attempts to store more data in an array (buffer) than it was intended to hold, thus overwriting the return address of the function. To show how this is actually done, I'll explain how to do a simple attack on a fairly small program."

Comments

News?

[American AC in Paris]

Look, this may be useful information, but it's not even remotely newsworthy. It's a freakin' intro-level homework exercise.

What's next, "How To Conduct Your Very Own Segmentation Fault"?

Re:News?

[hoka]

Seriously, buffer overflows are not only simple attack vectors, there are multiple ways to deal with them (hardware and software). All the hardened distros I know of use something to prevent it (Active Bounds Checking, Stack Smashing). What people really need to be aware of are things like SQL injection attacks, Cross-Site Scripting attacks, social engineering, and people should also know how to configure their machine to limit data penetration once the user is inside (ACLs, Chroots, jails, etc). I suppose I can't be all that mad, since most people really don't understand attack vectors in the first place, let alone how any one vector works.

Re:News?

[IainMH]

Look, this may be useful information, but it's not even remotely newsworthy. It's a freakin' intro-level homework exercise.

Hey hang on there horsey. This is a good article. Why shouldn't it have a place here? If you don't want to read it, don't read it. /. is a place were news and more importantly and community convenes to learn a little bit more each day about our (nerdy) world.

I for one enjoyed this article. Don't complain if some article don't conform to your expectation of what you think /. should be.

Re:News?

[Otter]

This is a good article. Why shouldn't it have a place here?

No, it's literally an intro-level homework exercise. It's a code snippet copied out of a textbook.

Re:News?

[evilrip]

Uhm , if all the hardening make the distros so secure, why are they still getting owned via one or another variant of the buffer overflow (stack or heap based, overflowed, underflowed, integer manipulation, etc). Although I agree that the point of entry often is via other types of attacks when the attack is happening from a remote location and not locally, say like php-code injection, sql-manipulation, perl fun, etc. The x86 especially has poor protection from attacks of the buffer overflow kind as most protection is software based, which is really a failed approach. That said, make no mistake and think that a cpu with a no-exec bit for writeable pages or similar will make you entirely safe either. The x86 isn't alone about this problem but it sure is amongst the most vulnerable to it. Thankfully, exploiting buffer overflows is becoming harder even on the x86(depending on OS, hardware, etc), but it's still far from immune. This was alotta text to waste just to say what others have said time and time again before me. And everyone knows about the legendary phrack(p49 article 14) article by alephone that beat this one by what, 9 years?

The Tao of Windows Buffer Overflow

[nweaver]

Another good reference is the Tao of Windows Buffer Overflow by the Cult of the Dead Cow. A very detailed explanation how to exploit stack overflows on Windows.

Smashing The Stack For Fun And Profit

[bajan_on_ice]

Read what I consider the seminal hacker work on this subject by Aleph One over at phrack.org

http://www.phrack.org/show.php?p=49&a=14

A little on the detailed side, especially the gdb stuff, but a GREAT article.

Re:Once again, Zonk lowers the bar.

[thundercatslair]

Lowered? I didn't think that it could go any lower.

A shame...

[diegocgteleline.es]

Why people does care so much about creating buffer overflows. Just write programs in C/C++, you WILL create buffer overflows. It seems that most of programmers can't avoid them and "buffer-overflow vulnerabilities" are found all the time. Why not care instead about the methods created to fix (most of) them? The ones that many distros are still not shipping despite of being quite obvious that they're need more than the latest KDENOME shit?

Just check the debian security mailing list and look how many buffer overflow security bugs are there: Too many. Too many for something which is know to be (partially) fixable with kernel/compiler tricks. Did GCC 4.0 included finally that FORTIFY thing that includes both compile-time and run-time "buffer overflow protections" BTW? That is interesting, not learning how to create buffer overflows.

Re:Once again, Zonk lowers the bar.

[Anonymous Coward]

Mods should have the guts to mod the parent insightful. Speaking up is the only way to prevent our favorite reading forum devolving into a tool for people to drive hits to their websites. I come to /. because I can depend on it doing the filtering for me. If the standards are lowered here, I stop visiting and so will others. For those who say "just don't read it if you don't like it," you're missing the point--the beauty of /. is that we can come here and be assured of a quality read, not a vast dumping ground that we then have to further sift. When abusers like Roland Piqupaille (or whatever his impossible last name is) or this guy (who cribbed it from a book) can make Slashdot do their bidding, we all lose.

Re:Here's a sample...

[Beatlebum]

this is getting really tiresome.

Did it occur to you that the sequence JMP ESP could be there by pure accident? It's just two bytes, perhaps it could be there at an irregular offset of a compiler generated assembly sequence, or perhaps it could be there as part of an address in memory. Get it now?