How to explain buffer overflow to a layman
security.stackexchange.com
security.stackexchange.com
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).
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.
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.
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.
:)
Next: 'Fatal Bus Error'. Car analogy please!
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.
That's all I got ;)
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.
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.
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.
"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.
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...
Looking back at the BOFH it was actually surprisingly educational.
Now, here's Conway Twitty...