How to explain buffer overflow to a layman

Question

Every once in a while (when I think out loud and people overhear me) I am forced to explain what a buffer overflow is. Because I can't really think of a good metaphor, I end up spending about 10 minutes explaining how (vulnerable) programs work and memory allocation, and then have about 2 sentences on the actual exploit ("so a buffer overflow fills the buffer up with nonsense and overwrites the pointer to point to whatever I want it to point to"). By this time, most people have become suicidal... What is a good way to explain a buffer overflow to laymen? If possible, please include an "overflow" component, but also at least a lead-in to why this means the attacker can get what he wants. Remember, people of average (and below average) intelligence should be able to get an idea of what I am talking about, so while you should absolutely feel free (encouraged, actually) to explain what each part of your metaphor (analogy?) represents, don't rely on any super-technical descriptions...

PS, a related question explaining in technical terms what the buffer overflow does: What is a buffer overflow?

Answer 1

Imagine you have a list of people you owe money to.

Also, when you write over something, it replaces what was there before instead of writing over the top of it. (The analogy breaks down a bit here, because you pens don't work that way in real life, but computer memory does)

You pay someone a $500 deposit on a $5000 car, so you now owe them $4500. They tell you their name is John Smith. You write the amount (4500) and the name (John Smith) in the table. Your table now looks like this:

Later your table reminds you to pay them back. You pay the $4500 (plus interest) and erase it from the table, so now your table is blank again.

Then you get a $1000 loan from someone else. They tell you their name is "John Smithxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9999999999". You write the amount (1000) and the name (John Smithxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9999999999) in your table. Your table now looks like this:

(the last 0 from 1000 was not written over. This is unimportant.)

When writing the name, you didn't stop when you got to the end of the "name" column, and kept writing into the "amount owing" column! This is a buffer overflow.

Later, your table reminds you that you owe $99999999990 to John Smithxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. You find him again and pay him almost 100 billion dollars.

Answer 2

The idea of using up more space than you were given, and therefore spilling over into a different field is simple enough to visualize. But it probably isn't clear how this can lead to a bad guy running his own code.

This is pretty simple to explain if you understand it well enough. Just make sure you hit on the important background. More or less in this order:

• The "stack" is a place where you can store temporary information. The "stack pointer" determines where the end of the stack is. When a function runs, it moves the stack pointer to give itself memory to work with, and when it's done, it moves the pointer back where it found it.

• The stack grows backwards. So to give yourself 100 bytes on the stack, you subtract 100 from the stack pointer rather than adding it. If the previous function's stack started at 1000 and I want 100 bytes, then my stack starts at 900.

• This means that if you use more space than you gave yourself, you won't just continue writing out into empty space, you'll actually start overwriting previous stack values.

• When my function starts, the very top value left on the stack for me by the previous function is the return address where I should go when my function is done.

• This means that if my function overruns its stack, the very first thing that it's going to overwrite is the return address. If the attacker is careful about what he fills the stack with, he can specify whatever return address he wants.

• When my function exists, whatever code is at that return address is what will get executed next.

Simple Example

In Smashing the Stack for Fun and Profit, where this technique was originally described, the most simple and straight-forward technique was introduced. Imagine the function reads your name and then returns. So your stack looks like this:

Stack Pointer                                      Prev. Stack Ptr
+----------------------------------+--------------+................
| Your Name Here                   | Return Addr  |  Old stack ...
+----------------------------------+--------------+................

But the bad guy makes his name long enough to overflow the space. And not only that, instead of typing a real name, he types in some Evil Code, some padding, and the address of that Evil Code.

+----------------------------------+--------------+................
| [ Evil Code ]xxxxxxxxxxxxxxxxxxxxxxEvil Address |  Old stack ...
+----------------------------------+--------------+................
  ▲──────────────────────────────────┘

Now instead of returning back to the previous caller, you jump straight to the [Evil Code]. Now you're running his code instead of your program. From there it's pretty much game-over.

Mitigation and Other Techniques

Two of the techniques used to reduce the effectiveness of stack smashing are DEP and ASLR.

DEP ("Data Execution Prevention") works by marking the stack non-executable. This means that the [Evil Code] on the stack won't run, because running code on the stack is no longer allowed. To get around this, the attacker finds chunks of existing code that will do bits and pieces of what he wants. And instead of just overwriting his own return address, he creates a chain of return addresses down through the stack for all the functions he wants to run in turn. They call this "Return Oriented Programming", or ROP. The chain of returns is called a "ROP Chain". This is really hard to do. But there are tools to help.

ASLR ("Address Space Layout Randomization") works by randomizing the locations of all the interesting functions. Now creating a ROP chain isn't so easy -- every time the program runs, all the addresses are in different places. So when the attacker goes to overwrite the return address with is own Evil Address, he won't know what numbers to use because the code is always in different places.

Neither DEP nor ASLR on its own offers much protection, but both together make successful exploitation very difficult. While some circumventions sometimes exist, there isn't a workaround that works everywhere. If you can get around DEP+ASLR, it's a one-off sort of success.

Answer 3

The other answers are still pretty technical, so I am offering this.

Let's imagine you have a kindergarten class. There are cubby holes for each student to put their shoes in. Each cubby hole holds one shoe. So for each student, you provide two cubby holes.

Each student is assigned two adjacent cubby holes. The teacher then calls students at random to put their shoes into the cubby holes to which they are assigned.

When the teacher calls up Bad Billy Bad Billy wants to mess with Stupid Sally. Billy's cubby holes are numbers 5 and 6 and Sally's are numbers 7 and 8. Billy puts his shows in 5 and 6 and then overflows his defined limit and puts a slimy toad in Sally's cubby number 7.

Because the teacher is not enforcing any protections on the defined limit for using cubby holes in the adjacent order, Billy is able to overflow his limit and mess with Sally's storage. Now when Sally goes to get her shoe, she will get a slimy toad instead yuck!

---

+-------------------+--------------------+-------------------+--------------------+
|      CUBBY 5      |       CUBBY 6      |      CUBBY 7      |       CUBBY 8      |
+-------------------+--------------------+-------------------+--------------------+
|                   |                    |                   |                    |
| Billy's Left Shoe | Billy's Right Shoe | Sally's Left Shoe | Sally's Right Shoe |
+-------------------+--------------------+-------------------+--------------------+

Billy input three items where it is defined he should only put in 2, this is how a stack overflow works at a high level, someone is messing with storage for which they are not authorized and then when that storage get's read it's not what you were expecting.

+-------------------+--------------------+------------+--------------------+
|      CUBBY 5      |       CUBBY 6      |   CUBBY 7  |       CUBBY 8      |
+-------------------+--------------------+------------+--------------------+
|                   |                    |            |                    |
| Billy's Left Shoe | Billy's Right Shoe | Slimy Toad | Sally's Right Shoe |
+-------------------+--------------------+------------+--------------------+

A buffer overflow could have been prevented if the teacher was paying more attention and ensuring that each student only used the amount of storage which was expected.

Answer 4

I'll try this without using any analogies.

A computer is basically all memory, that's the important part, the contents of memory are instructions, which tell the computer what to do, and data, which the instructions make use of and can use or modify. Frequently it's necessary to store data which has a variable length. For example, if a program has to keep track of someone's email address that could be very short (a@b.com) or very long (first-name.middle-name.last-name@mycustomdomainname.co.uk). Some programs don't keep track of the maximum length of their data records very well. So if a program was designed with a maximum of, say, 100 characters for an email address and someone gave it an email address with more than 100 characters the program would just continue writing the rest of the address in memory past the end of its pre-allocated space. The important part to remember is that the memory is everything, the program itself is in memory right along side the data records.

Someone who knew exactly how this program worked could give it a very carefully crafted email address that was very long and had special characters at the end of it. The idea being that when the program stored the email address in memory it would blindly write those special characters to a part of the memory where the program thought other parts of itself were, and then when it went to run those parts it would instead run whatever program those special characters translated into, in computer code. In that way it would be possible for someone to get the computer to run anything they wanted it to, just by carefully crafting the data they gave to the program.

Answer 5

Good question. Here's an analogy that isn't the most technically accurate, but it should get the idea across.

Picture a recipe book on 3-hole punch paper in a binder (memory) and a very dumb cook (the processor, i.e. the CPU).

• People can add or remove pages from the binder (load or unload programs and data in memory)
• The cook just follows every instruction on the page they're on
• The cook starts at the beginning (bootloader) and continues on until the instruction is "close book"
  • Even if the instruction is to flip to another page (Turn to page 394)

So, normally, you'd write on page one "Turn to page 200 (waffles)", open up the binder, and put in waffles at page 200. Then have the cook start - the cook should make waffles!

But wait... there's an attacker! They've written notes in the margins of your waffle recipe (outside the buffer) - and the cook executes those instructions even though they're obviously handwritten.

The cook was never told to only do what's printed on the original sheet (in the normal buffer space) - the cook will also do anything after that (in memory after the buffer).

Perhaps the cook adds vinegar to the waffles (corrupts your files). Perhaps the cook turns to page three hundred and ninety four and just leaves the raw egg sitting there, unused, until it rots and molds (turns off your antivirus). Perhaps the cook throws away everything in the kitchen (deletes all your files), or puts a lock on your kitchen door to keep you out (ransomware), or opens the window (installs a trojan/backdoor) so the attacker can climb in the window.

Answer 6

I always explain it as like bursting a bucket. The bucket is there to protect the contents from the outside and vice versa, but you're using the contents to get to the outside of the bucket, and therefore access to areas of the system that you should not otherwise have access to.

Answer 7

How's this?

The data in a computer is stored as a long list of numbers, like the tracks on a music cassette. Unlike music, which is played from the start to the end, computers need to jump around from one track to another, so they need a 'track listing' to tell them where each one starts.

Track lists are easy for music, since each song has a known length. With a computer, the amount of data we need to store might not be known yet, for example if it's coming in from the Internet. If the track we're using fills up, we need to switch to a different, unused one. If we don't, for example if we wrongly assume that we'll never be given more than a certain amount of data, we might use up too much tape and 'tape over' the next track. When a program tries to read that next track, it will get back part of our data instead of whatever was there before.

This can be dangerous, because the overwritten data might have been a set of instructions to carry out. If so, the computer will now be carrying out instruction downloaded straight from the Internet!