The analogies in the post seem a bit overly complicated to me. Keep it simple.
Let's say I have an empty glass (memory allocation). I know ahead of time that the maximum capacity of that glass is 8 ounces. A buffer overflow is what happens when I overfill that glass. If the amount of water in the glass stays less than 8 ounces, no problem. If it overfills, I don't quite know where it'll go. It might get into something it shouldn't be in (security, program instability, etc).
The examples in the answers show that it's not true "you don't quite know where it'll go" - you (or rather, an attacker exploiting buffer overflow) know exactly where it will go and that it won't just make a random mess, it can be used to make precise, targeted alterations to program execution. That's what makes it dangerous.
Exactly. The Stack Exchange example demonstrates the dangerous nature of buffer overflow attacks. They are not just about simple mischief (like archon's spilled water example is).
Um, I might be wrong, but AFAIK exactly "knowing" where water will go is pretty hard, almost impossible nowadays because of some hardware/OS improvements (like randomising offset for example).
And "glass model" is still fine anyway. If you know that glass stands on the piece of sodium you know there'll be problems ;)
The “glass over a piece of sodium” analogy is flawed too. It makes it sound like the program has to be special and dangerous for a buffer overflow to have dramatic consequences. It doesn't. It may be an ordinary program written to fulfill an ordinary task, and contain buffer overflows that are completely exploitable.
Check out my Cubby example. I saw the accepted answer and the others and then added mine. Thought the others were still pretty technical or too long. [http://security.stackexchange.com/a/53912/36538]
You've basically said "a buffer overflow is what happens when your buffer overflows". It doesn't explain how memory outside the buffer can be overwritten when it overflows.
A buffer overflow is like filling your gas tank with a burning match on the ground below the fill nozzle. If you put too much gas in the tank it overflows and your car explodes.
Imagine filling your car up with coolant, when you fill it up too much you expect it to fall into the overflow drain, but if you fill it up too fast you can bypass the overflow drain and end up with it making a mess on the engine. You may not know where it will make a mess, sometimes it will end up falling straight through to the ground, or you may end up getting some on your timing belt, but either way, you know you've overfilled your coolant. That's analogous to a buffer overflow.
Now imagine buying 10 gallons of coolant and repeating this experiment until you have a very good idea of exactly how to pour the coolant to make it land on the timing belt, or in other places, and that is a way to think about what happens when a hacker is exploiting a buffer overflow.
Damn it Theodores, I'm a programmer, not an electrical engineer!
Not a hardware guy but let's see, imagine being in 6th in a six speed, and trying to shift up. That noise you just heard? That's your gear shifter issuing back a 'bus error' that you have no more gears to use.
Maybe switch your glass to an ice cube tray. because you do know where it will go when it overflows- to the next memory address. you just don't know what side effects that may cause.
Let's say I have an empty glass (memory allocation). I know ahead of time that the maximum capacity of that glass is 8 ounces. A buffer overflow is what happens when I overfill that glass. If the amount of water in the glass stays less than 8 ounces, no problem. If it overfills, I don't quite know where it'll go. It might get into something it shouldn't be in (security, program instability, etc).