1

I guess there are similar questions and some data on the web...but I want to be sure that I grasp the concept correctly, since all online tutorials are way too long and focus on exploits, ect. So, the way I see it a simple buffer overflow will be something like:

//////////////////////////////////////////////////

  1. You send a string of arguments/input like that: nop instructions(x90) + shellcode + some text + address of some nop instruction.

  2. If the string is of the correct length it will override the return address ebp with the address of some of the nop instructions. Once it jumps there - it will then skip until reaching the shellcode....and the rest is history.

////////////////////////////////////////////////

I am more of a c++/php/c# type of guy and assembly and c are beyond my mental capabilities....lol...so seriously...or jokingly..is the description above something along the line? Plus, as far as I understand there are some protections against buffers ovs., though I don't undertand them yet. How will firewall catch this?

10x!

Ethan Heilman
  • 16,347
  • 11
  • 61
  • 88
joe
  • 11
  • 1
  • Duplicate of http://stackoverflow.com/questions/460519/how-are-buffer-overflows-used-to-exploit-computers? – dlanod Mar 11 '11 at 23:57

3 Answers3

4

Smashing the stack for fun and profit is a must read for anybody who is serious about understanding how Buffer Overflows work. You will find no better answer than what that white paper provides.

Edit

If you've already read Smashing the Stack and want to go further then may I suggest reading Hacking: The Art of Exploitation 2nd Ed

Hacking: The Art of Exploitation

Community
  • 1
  • 1
SiegeX
  • 135,741
  • 24
  • 144
  • 154
  • Thanks, it was actually my short guideline prior to opening this...post. This one and wikipedia. I see the article is old though...but very detailed. – joe Mar 12 '11 at 00:09
  • this seems interesting, will have a look...when i have more time. – joe Mar 12 '11 at 00:24
  • I have that Erickson book - it's awesome. Highly recommended if you're interested in that sort of thing. It's full of assembly code, low level C, etc. so it's not for script kids looking to hack javascript. – David Mar 12 '11 at 16:54
1

Yes, that's one way to explore a buffer overflow. This book is a great reading.

I'm not aware of any firewalls with capabilities to monitor buffer overflows on other applications (if that is what you mean).

karlphillip
  • 92,053
  • 36
  • 243
  • 426
  • Yes, I meant a firewall monitoring any incoming requests on say port 80. Would it be possible such a firewall to simply drop any request which contains say x90 hundred times? Normally no user will ever need to access a URL containing a bizarre hex string. – joe Mar 12 '11 at 00:07
  • @Joe I think you might be a bit confuse mixing sockets, buffer overflows and firewalls. But I'll play along: what happens if 0x90 has a special meaning for the application listening on port 80? What if 0x90 is a part of a communication protocol used by the application? It doesn't sound a good idea to me. – karlphillip Mar 12 '11 at 00:15
  • Can't you simply "trycatch" it? I mean if the buffer overflow exploit reaches the vulnerable process at first (the webserver...) it will spawn a shell - however the way i see it...if it reaches another app there is almost 100% chance that it will cause some segmentation fault...or simply nothing will happen. Whatever the case it really depends on how the firewall will analyze the string -if it can read it as ascii - then it's all ok, if it's already in assembly...then it can be difficult, but still possible perhaps. – joe Mar 12 '11 at 00:23
  • @Joe As I said: you described ONE way to do it. You don't really need the NOPs in front of the buffer. It makes things easier indeed, but you still can make a successful attack without it. Whoever writes an exploit using the NOP technique can very well do it without it. – karlphillip Mar 12 '11 at 00:29
0

Specifically, what you are describing is known as a NOP sled (or "slide," or "ramp"). Here is an article that provides a real-world honeypot example of this.

You can protect against an attack like this by, for example, limiting the number of characters you read in to less than the size of your buffer. More generally, network intrusion detection tools like Snort aim for broad detection and prevention in case things like lack of input validation happen to go unnoticed.

ty.
  • 10,924
  • 9
  • 52
  • 71