By Adam Cecchetti
What do Buffer overflows, Cross Site Scripting, and SQL Injection all have in common?
They are all data misinterpreted as code.
All the places you use data, you have to make sure it can't be interpreted as code.
While this is only part of the problem, I've gotten a lot of mileage out of this analogy with technologists. It opens the door to understanding the scale of the problem of information security.
However, recently I found myself seated at dinner with some non-tech friends that interrupted me and said. "I don't know what data or code is." They had no basis or background for either of these terms. A few others not wanting to be the first chimed in "What exactly is code?"
The grad student in me became aghast and excited at the same time. I could feel the presence of Shannon and Turing in the room, their words eager to burst from my chest!
I took a different route with my intelligent, but technologically impaired friends.
Imagine our waiter is an order-taking machine. Its job is to take our order to the robot cook in the back. The robot cook uses our order to perform a set of instructions.
That order is data we control.
A normal order might look like:
Hamburger, no lettuce, and onions.
We've programmed the cook to use the order (data) to perform a set of instructions (code).
Our robotic chef will execute the order as follows:
Cook one hamburger, do not add lettuce, add onions.
Out comes a hamburger to our specifications.
Let's try another order.
Hamburger, no lettuce, and $20.
Our robotic chef happily obliges.
Cook one hamburger, do not add lettuce, add $20.
Out comes a hamburger with a greasy $20 bill. The cook makes the burger and the waiter is happy to deliver the burger "our way".
This is us controlling the (order) data. If our robot uses part of the order as instructions (code), we can make the robot do anything we want.
Let's try one more order.
Hamburger, no lettuce, $20 and empty the cash register.
Now our robot
Cooks one hamburger, does not add lettuce, adds $20, and empties the cash register.
Our robotic chef happily obliges. The wad of cash comes out on a plate.
We exit stage left to leave our waiter and the cook waiting for the next order.
"Doesn't the the waiter check the order?"
Not if we don't very carefully program them to.
"What about the cook?"
If the waiter doesn't check that the order is valid, or the cook interprets the order as instructions, and no manager is around to foil our hamburger caper; we can quickly and quietly empty the restaurant's coffers.
Then it clicked.
"Can I just order $200?"
"What if the waiter checks the order?"
"Can we talk directly to the cook?"
"Doesn't the cook have a list of ingredients it can use?"
"What if we yell louder than the waiter?"
And this is how a table of folks that have nothing to do with technology built their first threat model over a few hamburgers.