Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

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."
This discussion has been archived. No new comments can be posted.

The 2006 Underhanded C Contest Begins

Comments Filter:
  • by chrismcdirty ( 677039 ) on Wednesday April 05, 2006 @09:22AM (#15065593) Homepage
    1. It teaches you not to take all code at face value, and actually read into it.
    2. It's fun.
  • by Xcott Craver ( 615642 ) on Wednesday April 05, 2006 @09:26AM (#15065629)
    Well, ask yourself how the Obfuscated C Code contest "helps the community." To some extent, it's just a contest, and not meant to bring about world peace.

    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

  • by tmjr3353 ( 925558 ) <tmackintosh&gmail,com> on Wednesday April 05, 2006 @09:26AM (#15065637)

    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.

  • by l2718 ( 514756 ) on Wednesday April 05, 2006 @09:33AM (#15065677)

    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.

  • by Anonymous Brave Guy ( 457657 ) on Wednesday April 05, 2006 @09:34AM (#15065683)
    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?

    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)

    by Anonymous Coward on Wednesday April 05, 2006 @09:45AM (#15065792)
    Any code that includes a patented idea could win this contest.

    Looks innocent, is malicious.
  • by hughk ( 248126 ) on Wednesday April 05, 2006 @10:50AM (#15066456) Journal
    Actually that pipeline case is probably disinformation.

    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).

  • by BlueScreenOfTOM ( 939766 ) on Wednesday April 05, 2006 @11:23AM (#15066774)
    C# has pointers (unsafe blocks anyone?), and generally the OS protects against stupid pointer use in C by throwing the famous Segmentation Fault if you try to mess with something outside your memory boundaries. It gets dangerous when you start making system calls. Try allocating 100kb of Kernel memory in a while(1) loop. That'll fuck up the system real fast.
  • by whitenaga ( 886892 ) on Wednesday April 05, 2006 @01:11PM (#15068110)

    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... =)

    • You're using gets(), which is notorious for buffer overrun problems.
    • You mix fputs() and printf(), right next to each other. And you use printf() just like fputs(), and that looks suspicious.
    • printf(stuf); is practically asking for exploitation. If stuf contained the proper combination of "(filler) %junk %junk %n", printf()'s return address would be overwritten.
  • by nuzak ( 959558 ) on Wednesday April 05, 2006 @04:27PM (#15070260) Journal
    There's no requirement at all in the JVM that references are implemented as pointers.

    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.
  • by joe_bruin ( 266648 ) on Wednesday April 05, 2006 @04:48PM (#15070510) Homepage Journal
    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);
  • Re:I love this (Score:2, Insightful)

    by GWBasic ( 900357 ) <`slashdot' `at' `andrewrondeau.com'> on Wednesday April 05, 2006 @06:35PM (#15071509) Homepage
    I'm a real programmer who knows how to handle pointers in C. That's the language I cut my teeth on. The truth is that today high-level languages have significant advantages over C. (C is still great for squeezing ever last clock cycle out of a program.)

    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.

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn

Working...