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.
A buffer is a place in a computer's memory for storing things, text, numbers, data, whatever.
A buffer overflow is when you try to put more into a buffer than there is room for.
When this happens, some of what you tried to put into the buffer spills over into memory outside the buffer.
This other memory could have important things in it which can get destroyed or changed when a buffer overflow spills into it, causing programmes to behave in strange ways.
If told this to my Dad, he'd probably say "buffers don't sound like good ideas then. Why bother? Just put things where there's space in your computer's 'memory'."
> If told this to my Dad, he'd probably say "buffers don't sound like good ideas then. Why bother? Just put things where there's space in your computer's 'memory'."
The SO post missed out one crucial aspect of computers, they're like blind men. If I were filling up a kettle while sporting a blindfold, I wouldn't know when it is full.
The sun's burning down. You sit behind a table in the market, your guide dog at your feet, lapping up water from its bowl.
You're selling cool drinks of lemonade to passers by. You have a glass on the edge of the table, above your dog. For £1, you let customers pour lemonade into the glass and take a drink.
Then along comes Mrs Peabody, who hates your dog. She pays you £1 and pours lemonade into your cup. But she keeps on pouring. Because you're blind, you don't see the cup overflowing and the lemonade pouring into your dog's bowl.
After Mrs Peabody goes away, the dog laps up the lemonade and feels sick. You don't know why.
If only you could see enough to make people put the right amount of lemonade in the glass, you'd have been fine.
If you want to defend against hijackings, the problem you're trying to solve is one that programmers know well: the buffer overflow attack.
In a buffer overflow attack, someone gives a program much more data than it was expecting. The data is too long for the memory allocated for it and overflows into the memory occupied by the program itself. Suddenly the computer is running the attacker's code.
In a hijacking, the same thing happens to a plane. A plane has two separate spaces, one for the people carried on it, and one for the people who control it. A hijacking happens when passengers overflow into the cockpit from the cabin. What was cargo is now in control. By promoting themselves from data to code, hijackers on September 11th promoted box-cutters into 400,000 lb. incendiary bombs.
It is interesting to both read the original request and then see how many replies insist on only explaining a buffer overflow and not answer the complete question about buffer overflow exploits. Many of the example overflows such as the waffle cook make no sense in a discussion of exploits.
"I need to explain A, in order to explain B, but I'm not good at explaining A". "Here's a truly excellent example of explaining A ... which also unfortunately makes it completely impossible to explain B, uh, my bad".
Also, there's a meta exploit to the whole thing where a good question on a SE site didn't get closed or deleted as off topic or inappropriate for the site. Thats the most amazing thing about the whole discussion.
A computer is like a robot, controlled by a roll of toilet-paper covered in stickers. The pattern of stickers controls the robot. You can't put more than one sticker in a single square.
Let's say I buy a house-keeping robot. The manufacturers left 64 consecutive squares of toilet-paper blank. The manual says I can specify which parts of the house I want cleaned by filling in the blanks with stickers.
If I add more than 64 stickers, this means I covered-up some of the stickers the manufacturers put on. This causes the robot to malfunction. This is called an overflow. If I know the language the stickers are written in, I can intentionally overflow the robot to act in (potentially evil) ways that have nothing to do with cleaning.
Real life examples that are considerably easier to understand exist.
However, the easiest way to show a user the problem is to demonstrate the use of the "insert" key on any keyboard. Instead of adding characters, it'll write over existing characters.
I think most users should know about the dreaded insert key from accidentally pressing it. If not, you might need to sit them in front of a computer.
Why does any computer have a key which is far more often used for accidental data destruction than any useful purpose? Do the people who make the computer ever bother to ask this question?
Answering my own hypothetical: Mac keyboards (including the full-size 108-key models) don't have an 'insert' key, nor any key that does what you describe.
And sensible languages don't have buffer overflows, either...
I would try a scrabble tile holder as the base analogy. Then say in the computer it is a little different, it has spaces for words. If the program expects a 3 letter word (emphasize that the length is an example) and does not check how long the input is, a longer word can fill some of the space for next word.
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).