The 2006 Underhanded C Contest Begins 232
Xcott Craver writes "The second annual Underhanded C Code Contest is live as of April 4th, and runs until July 4th. The object is to write malicious C code that looks perfectly readable and innocent under informal inspection of the source."
Re:Can someone explain this to me? (Score:5, Insightful)
2. It's fun.
Re:Can someone explain this to me? (Score:5, Insightful)
On the other hand, I think it does teach us a thing or two about what to look for when reviewing code. I know I've learned a lot about sneaky coding practices since it started. I learned C in the 1980s and thought I was pretty knowledgeable by now, but I actually didn't know about ASCII trigraphs until last year. X
Re:Can someone explain this to me? (Score:5, Insightful)
I understand about making source code available helps in a secure system, but what if that code has evil code...made to look innocent upon inspection....written into it?
I think you've highlighted the point right there. By getting the community to find ways to write code of this fashion, you're simultaneously getting them to learn to read code better (or at least that would be my hope). If I know how to write code in a fashion that looks innocent but brings with it not-so-innocent consequences, then hopefully I know how to tell when someone else is doing the same thing.
Re:Can someone explain this to me? (Score:5, Insightful)
This problem arises whenever you need to use software for an application that must be secure. One famous case of tampering was by the CIA; control software for a Soviet oil pipeline purchased in the West was modified to fail upon a remote command [msn.com] causing a massive explosion.
One hypothetical scenario: Diebold [diebold.com] decide to act on their CEO's promise to deliver the election to the Republican party by making a small modification to their voting machines [diebold.com]. If they can use the techniques this contest is looking for they would write the code so that it would escape even scrutiny by an outside agency (say, the government).
In general, the idea of the contest is to showcase ways of breaking security and therefore perhaps ways to overcome them.
Re:Can someone explain this to me? (Score:4, Insightful)
The "many eyes" theory can only work in practice if there are indeed many eyes reviewing the source code and those eyes can see any problems. That doesn't just mean accidental bugs, or portability/future-proofing concerns, or a poor choice of data structures and algorithms leading to a performance hit. It also means spotting the devious and subtle attacks.
Just imagine what would happen if a major OSS project like Apache or Linux accepted a "useful" patch that contained a backdoor that wasn't identified, and this then got distributed worldwide. A significant number of people believe, erroneously, that using OSS inherently makes them safer because of the many eyes theory. These people will happily download and build the updated code, or install prebuilt binaries with correct checksums, completely oblivious to the fact that they just stuck a major security hole in their system.
Thus it's important for those who review submissions to software development projects - OSS, commercial or otherwise - to be very aware of these possibilities, and likewise for anyone else who contributes to them so they can spot a problem if they come across it.
Any code (Score:2, Insightful)
Looks innocent, is malicious.
Re:Can someone explain this to me? (Score:3, Insightful)
The Trans-Sib pipeline control system was developed by a UK company. It used MC6800s and was written in assembler. The stuff was so unstable anyway due to the hand coded networking that deliberate interference would hve been picked up during the shake down (the code was continually being rewritten and EPROMs reblown).
Re:Any C code is potentially malicious (Score:2, Insightful)
Dangerous and suspicious looking (Score:4, Insightful)
Your code is dangerous, but it has to be exploited by a knowledgable user. I think what they're looking for in the Underhanded C Contest is code that exploits itself. But for the purpose of being pendantic, i'll bite... =)
Re:Any C code is potentially malicious (Score:2, Insightful)
Pointers POINT to arbitrary memory locations. References do not. You cannot recast a reference to an arbitrary type, you can't put arbitrary data at a reference location, you cannot reseat a reference with a new instance, you cannot do pointer arithmetic with references.
It happens that pointers can be like as references, among many other things. This does not make references into pointers.
Re:My entry -- the world's last C bug (Score:5, Insightful)
Look again. This time, look for any extra semi-colons that shouldn't be there. The responder's joke was an improvement on the original, and would not have been flagged by an optional compiler warning (at least in the case of gcc).
if(status == 1);
Re:I love this (Score:2, Insightful)
Example 1: In my senior year of college, I took an AI class. The professor allowed us to do homework in C, LISP, or Java. My parter and I avoided LISP because we didn't see any benefit in learning it. We chose Java instead of C because we needed many features that are built into the language; using C would have doubled the time we spent coding and debugging. In the end, we recieved As on our assignments because they worked; the kids who were crazy enough to use C didn't get very far.
Example 2: I currently work in C# and use a CPU-intense module written in C++. C# allows me to write code faster, but keeping the CPU-intense parts in C++ allows the project to still perform as fast as we need it to.
To stay on-topic, such a contest would be more interesting if they chose a higher-level language. In C#, it's very easy to hide CPU-intensive operations in a single line of code. This is because one can have a property that goes and does something like a 10-second database query.