Before we continue the exploration into security vulnerabilities of drive-through restaurants... Eric Lippert has returned from his holiday of pre-recorded posts on mind-bending C# trivia, and come out with a rather amusing analysis of airport check-in queue strategies, based on analytic queueing theory.

I’m comforted to know that I’m not the only one to go to town on analysis of everyday things.

And now, back to our regular programming...

Drive-through optimisation

Last time, I set the scene of a restaurant drive-through, with the hopes of illustrating how innocent optimisations can introduce security vulnerabilities if we’re not careful.

We forgot to do our threat modelling! Nobody stopped to ask the question “what are we changing? what does this affect? how could this compromise our security?”

The “null-order”

Let’s consider the “null-order”: An in-store customer reaches the head of the queue, walks up to the counter, and realises that she doesn’t have any money. The order transaction is safely aborted and the customer leaves. There is no need for the restaurant employee to enter the “null-order” in their computer because there is no order to be made, duh! (Note that the customer realised the lack of wallet before placing the order.)

Now lets consider a “null-order” for the drive-through interface: A customer joins the back of the queue and is (often, but not always) in a single-lane one-way traffic system, where the only way out is to drive through the whole system: past the order point, the pay window, and the delivery window. If the drive-through is busy, there will be other cars occupying this space so the driver is stuck — they cannot escape the pipeline.

When they realise they have no money (again, before placing the order) they will place a “null-order”. The employee will not enter the “null-order” into the computer because there is no order being made. Duh! The customer wants to leave the queue at this point but she is stuck, so has to drive to the payment window. She must then execute a “null-payment” and explain to the cashier that no payment is necessary because no order was placed. Duh! No problem. Then the customer drives to the third window, staffed by an employee whose job is to deliver food to the cars as fast as possible, preferably with a smile.

The exploit

So what does all this have to do with security vulnerabilities of concurrent pipeline processing?

Well, one fun example of a non-software exploit is the fast-food drive-through free food scam:

1. Go to the drive-through of a fast-food restaurant and make sure there is someone behind you in the queue.
2. Don’t order anything (say you forgot to bring money).
3. Go to the pay window and say you didn’t order anything.
4. Proceed to the order pick-up window and collect the food that the car behind you is currently paying for.

Security specialist Bruce Schneier describes this in more detail and offers some solutions.

One solution

Continuing with my previous analogy: Since the order-point employee didn’t enter the “null-order” into the system (duh!) it didn’t get pushed onto the internal order queue. At that point the internal order queue was no longer synchronised with the physical queue of cars. Therefore, the cashier didn’t know she was expecting a “null-payment” from this customer, but this could be explained away by the customer. If the customer doesn’t also explain this at the order-delivery window they will be handed the order placed by the car behind (which is currently being paid for right behind them!)

By introducing this pipeline optimisation, we’ve suddenly introduced the need for the in-sore systems to be able to process a “null-order”, which sounded like a ludicrous idea for the in-store scenario, but is actually essential for keeping the drive-through queue synchronised with the internal order queue.

As I said before, security is a burden that you must carry through any refactoring, optimisations, or other changes; even those that seem unrelated.