5th Underhanded C Contest Now Open

Xcott Craver writes "The next Underhanded C Contest has begun, with a deadline of March 1st. The object of the contest is to write short, readable, clear and innocent C code that somehow commits an evil act. This year's challenge: write a luggage routing program that mysteriously misroutes a customer's bag if a check-in clerk places just the right kind of text in a comment field. The prize is a gift certificate to ThinkGeek.com."

Comments

Easy?

[Monkeedude1212]

Public Static String default_Address = "1600 Pennsylvania Ave NW, Washington, DC 20500, USA" --- hide this somewhere

Private Sub Void Route_Bagggage(bag b)
{
if (comment.text == NULL)
{
b.destination = default_Address
}
else
{
b.destination = comment.text
}
}

Or do I have to make it slightly more deceptive?

Re:Easy?

[Anonymous Coward]

In other words, you need to replace an == with an = in just the right location (or vice versa) so that while it looks like you're doing a sanity check, you're actually assigning a stealth variable.

To make it even better, you need to set it up so that this causes a buffer overflow, and you're actually overwriting another variable. THEN, you go back and do a sanity check on the original value which corrects the mistake caused by the ==/= replacement. That way, someone sees the mistake, but sees that it is properly handled and doesn't think twice about it.

Meanwhile, the adjacent address field has just been overwritten, and unless you're checking for overflows, you're unlikely to notice, unless you've already isolated the variable in a debugger. However, in this case, you're going to catch it no matter what... unless it's the pointer that gets overwritten and while you're watching the variable, it just doesn't get called anymore (even though the code implies that it does).

Sounds like fun :)

Possibilities

[Rei]

I don't have the time for something like this, but it seems to me a good possibility would be to have all of your inputs that the clerk fills out be contiguous in memory, including the destination, have the algorithm to figure out what destination to go to scan through the whole destination string looking for matches (rather than looking for an exact match) and taking the last one it finds, and have a broken bounds check for the length of that string so that the algorithm looks into the comments section as well.

So, for example, if the clerk fills out the destination as "LAX" but writes in the comments section, "Do not confuse his bags with those owned by CID who is also going to a different final destination; they're very similar looking.", the bags would be routed to Cedar Rapids (CID) instead of Los Angeles (LAX).

Re:Possibilities

[j-stroy]

It could be hidden in piece of user interface that todays systems are full of, the extra clicks and bells that no one needs, but some client or marketing weenie will never give it up.. overwrite the destination with the first bytes of an audio file with some misdirection.
Example on this page

Re:Possibilities

[bberens]

I could see this... have the front-end and back-end communicate over a socket or something and have a simple delimited message format where someone could alter the results by using a sql-injection style attack on your parser. That way, at least, the input has to be somewhat complex, but the code could look very innocent.

Re:This sounds familiar to,

[Anonymous Coward]

IOCC rocks!

korn.c is a good example, probably one of the best one-liner programs I have seen.

Re:Not fair!

[girlintraining]

Hardly. It is supposed to be "short, readable, clear and innocent". What are the odds that any of the airline production code meets that description?

Depends on the function -- if it's mission critical, you bet your ass it'll be documented and readable. Considering that most ATC technical failures are hardware, not software-based, that should say something. The problem is that while the code is quite well-documented, few people are left with the training or understanding of it to port it to newer systems, and it's not like they can ground all flights for a week to do an upgrade. So we're left with mainframes that were out of date in the 70s being used today being used in critical infrastructure.

On the other hand, the code in applications used at the ticket counter and security checkpoints... not so much.

Re:I'm really impressed

[troll8901]

Here's some points I'd like to highlight, from the 2008 Winners.

• Linus Akesson: The BYTESPERPIXEL macro "gives the false impression that the code intelligently supports higher bit widths" but actually "causes the 8-bit case to leak information into the file" (by exploiting a buffer overflow). ... (thus allowing wiped image data to be reconstructed.)
• Avinash Baliga: The ExpectTrue macro overwrites the image mask (by exploiting a buffer overflow), allowing two bits to survive the wiping, (thus allowing wiped image data to be reconstructed). Furthermore, the evil behavior is concealed in an innocent-looking error checking macro.
• John Meacham: (Winner) The code is "extremely simple, innocent, obvious" ... and devious. "Low-intensity pixels are replaced with a ‘0, and high-intensity pixels replaced with a ‘00 or a ‘000" ... (thus allowing wiped image data to be reconstructed.)

All I can say is, Wow.

Re:Not fair!

[Skater]

Does anyone else remember the new Denver Airport's original luggage system? This system singlehandedly delayed the airport's opening for over a year. Eventually the airport retrofitted a standard baggage moving system. If someone has access to the code of the original system, they could easily submit that.