Slashdot Mirror
The 2006 Underhanded C Contest Begins
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."
1. It teaches you not to take all code at face value, and actually read into it.
2. It's fun.
It's like sex, except I'm having it!
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
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.
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 causing a massive explosion.
One hypothetical scenario: Diebold 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. 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.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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... =)
Lindsey
@>-->-----
so if(status = 1) in his code is always true. In your code, not neccesarily. Hence, his is a bug. And funny.
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);