Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Security IT Technology

Underhanded C Contest announces winners 150

Matthew Skala writes "The 2005 Underhanded C Contest has announced its winners: the team entry from M Joonas Pihlaja and Paul V-Khuong, and the solo entry from Natori Shin. The contest (which appeared on Slashdot in June) tests programmers' ability to hide malicious behaviour in innocent-seeming code, making it a kind of evil shadow twin to the International Obfuscated C Contest."
This discussion has been archived. No new comments can be posted.

Underhanded C Contest announces winners

Comments Filter:
  • ...more malicious code writers.

    Thanks be to Slashdot for giving them the recognition/praise they so richly deserve.
  • A-ha (Score:2, Funny)

    by Anonymous Coward
    But Microsoft built a whole operating system based on the principle.
  • by bjorniac ( 836863 ) on Sunday September 18, 2005 @11:13AM (#13589804)
    Microsoft Word XP was rejected because the code had to seem innocent...
    • Re:Bill Gates Entry (Score:5, Interesting)

      by makomk ( 752139 ) on Sunday September 18, 2005 @11:34AM (#13589884) Journal
      Very true. For those of you who don't get it, one of the winners uses a technique very similar to the way Word (all versions AFAIK) leaks data into documents - an uninitialised buffer.
      • Re:Bill Gates Entry (Score:5, Interesting)

        by Richard_at_work ( 517087 ) on Sunday September 18, 2005 @11:45AM (#13589938)
        Found an interesting thing at work recently, during trials of VB.net and the .Net framework. Our VB.net programmers applications worked right up until one day, when suddenly, they stopped working. Simple things like messages in Message Boxes stopped appearing, or labels on buttons went astray, mouse cursor changes on mouseover events showing black boxes instead of the image. Very wierd we thought. He reinstalled the .Net framework, VS.Net, everything he could think of but nothing rectified the problems. We eventually found out what the problem was - McAffee Virus protection now includes buffer overrun protection. Turn that off, and everything worked fine. Wierd, just wierd.
        • Are you saying that your programs somehow depend on buffer overruns, or that Mcaffee's BOP is broken?
          • IM saying that the internal workings of .Net are ... interesting, or that McAffees BOP is broken. Our programs dont rely on buffer overruns, its all bog standard vb.net and the problem can be reproduced using small apps.
            • by pkhuong ( 686673 ) on Sunday September 18, 2005 @12:46PM (#13590163) Homepage
              The CLR does JIT (or, at least, runtime) compilation. A common way to do so is to output the machine code on the stack. W^X usually breaks programs that do runtime code generation. Now, this is a WAG, but that's where my money's at.
              • That's just poor design by the CLR JITC team. You can write a JITC that does not break BOP and other such stuff.

                But the CLR team would have to have gotten lazy, and not marked things as executable, and started exploiting other such things, just to save a few cycles.

                There's no reason why BOP should break the CLR.
              • by nothings ( 597917 ) on Sunday September 18, 2005 @02:17PM (#13590645) Homepage
                Who in the world generates code to the stack? Compiling code is expensive, so you want to cache it, that is, keep it around for a while, which means putting it on the heap.
                • Who in the world generates code to the stack? Compiling code is expensive, so you want to cache it, that is, keep it around for a while, which means putting it on the heap.

                  Well, you could make the compile function recursive. That is, compile a single method, then run it, and if it calls (at runtime) any other methods that haven't been compiled yet, call the compile function iteratively, passing a pointer to the point in stack where the code was executing.

                  So how do you figure out which methods are comp

                  • Cheney on the MTA by Henry Baker. Look it up. Basically, when you want tail-call optimisation (as in no stack depth limit, but not necessarily O(1) speed), but still want to use C, that's one of the best solution.

                    One solution (used in RABBIT, or a derivative, I believe), is to output everything in a big switch, and have each function call target be a case in it. (What about returns, you ask? You just CPS (transform into continuation passing style) the code first, so that every return becomes a call to the r
              • Scratch the stack part if you want. If the whole store is marked unexecutable by default, both methods will die if the CLR doesn't/can't mark the relevant pages as executable. Also, keep in mind that W^X emulation isn't available in vanilla Windows XP SP2, so if a third-party program somehow messes with the heap and stack to mitigate the effect of buffer overflows in the absence of NX, we can't really expect the CLR team to interface with that program to mark the relevant pages as executable (unless that pr
        • This may very well be due to a bug in McAfee VirusScan 8.0i, assuming that is what you are running. There was a bug fixed by Patch 6, I think. Patches are cumulative, so you can just apply Patch 11 and the problem should be fixed.

          Patches are not available from the public download location. You may need to have a support contract to get them.
  • good to see (Score:5, Insightful)

    by garat ( 899448 ) on Sunday September 18, 2005 @11:13AM (#13589805) Homepage
    Having a contest like this has similar positive aspects as full disclosure concerning vulnerabilities; by providing examples of how it's done, people will be better able to spot such attempts were they to occur. I'm happy to see this contest being held.
  • by Weaselmancer ( 533834 ) on Sunday September 18, 2005 @11:16AM (#13589812)

    Stashing all the entries in a 1.1M archive rather than posting links to the code. No way I'm going to download that just to see what all the fuss is about.

    • by RAMMS+EIN ( 578166 ) on Sunday September 18, 2005 @11:50AM (#13589958) Homepage Journal
      Moreover, who knows the archive isn't exploiting some buffer overflow vulnerability in my archiving software! Knowing who this file comes from, you'd be a fool to open it!
      • by glesga_kiss ( 596639 ) on Sunday September 18, 2005 @12:20PM (#13590070)
        They predicted that kind of paranoid response. From their (humorous) FAQ:
        Are you shills from MicroSoft trying to evangelize C-sharp?

        No, we are not shills from MicroSoft trying to evangelize C-sharp.

        Are you trying to prove open source is bad?

        No, we are not trying to prove open source is bad. If anything, this contest illustrates that we need more code review, not less.

        I bet you are government agents trying to entrap me.

        Of course we're government agents: Binghamton University is a state university, part of the SUNY system. Evil! Eeeeeeeeeevilllll!!!!!

        Do you know you've been Slashdotted?

        What, you couldn't tell from the last three questions?

        • Are you shills from MicroSoft trying to evangelize C-sharp?

          No, we are not shills from MicroSoft trying to evangelize C-sharp.


          No, they are from AcuCorp [acucorp.com], demonstrating how C really sucks sheep testicles, and how we should all be writing in COBOL or FORTRAN.

          Except, of course, for OS developers, who should write in Bliss [wikipedia.org].
      • by nEoN nOoDlE ( 27594 ) on Sunday September 18, 2005 @03:49PM (#13591194)
        Knowing who this file comes from, you'd be a fool to open it!

        but they would have known that only a great fool would open the archive given to him. I am not a great fool, so I can clearly not choose to open the archive. But they must have known I was not a great fool, they would have counted on it, so I can clearly open the archive supplied by them.
    • Stashing all the entries in a 1.1M archive rather than posting links to the code. No way I'm going to download that just to see what all the fuss is about.

      You visited the site?

      This is one I'll pass up, thanks.

  • by Krast0r ( 843081 ) on Sunday September 18, 2005 @11:20AM (#13589836) Homepage Journal
    "Prize: Since we're in Binghamton, NY, the prize will be a gift box from the nearby brewery Ommegang in Cooperstown, NY." Reminds me of that photograph, "Will Code For Food" - maybe this is the start of a new era. A combination of "free as in beer" and "will code for food".
    • by Anonymous Coward
      They actually are offering a ThinkGeek gift certificate of equal value to winners who don't want the beer or can't easily receive shipments of beer from the USA - so you can load up on Ballz and Penguin Mints and substitute caffeine addiction for alcohol addiction. Because that's so much better.
    • Do you mean "will code for free" or "Beer for food"?
      • Beer for food... after all, you can get complete nutrition for a day from 47 pints of Guinness, a glass of milk and a glass of OJ (calcium and vitamin C) .

        Whether you can drink 47 pints a day for more than a day or two in a row is a different story...
    • About 15 years ago, a friend who is a mathematician dressed up in street-bum clothes and had a picture taken of himself holding a sign that reads, "Will solve partial differential equations for food".

  • by $RANDOMLUSER ( 804576 ) on Sunday September 18, 2005 @11:23AM (#13589844)
    This one almost made it into the Linux kernel. It looks like error checking until you read it carefully.Short, brilliant and to the point.

    if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    retval = -EINVAL;

    In other words, you become root if you call sys_wait4()with the __WCLONE|__WALL) flags

    Story here [theregister.co.uk] and here [iu.edu]

    • by Anonymous Coward on Sunday September 18, 2005 @11:25AM (#13589852)
      This one almost made it into the Linux kernel.

      It *did* make it into the kernel for anyone using the BK-to-CVS gateway.
    • what's your definition of almost? Linus applied and reverted it again?
    • by jnf ( 846084 ) on Sunday September 18, 2005 @12:46PM (#13590167)
      to anyone who makes a routine of putting their constants on the left hand side of the expression, that becomes not very hard to notice .. although intermixed with several megabytes of source it becomes less obvious. What I mean is: if (( (__WCLONE|__WALL) == options && 0 = current->uid)) will throw an error, whereas 0 == current->uid will not.
      • The =/== is one of C's most dastardly tricks. It is a great way to make infinite loops too.

        That said - I think that C IDEs which perform context sensitive coloring should use two different colors for = and ==. Or maybe put in a macro or something to make it harder for these types of bugs.
        • why? the solution really becomes putting your constants on the lefthand side of the expression.

          It's really not that hard to get used to, i dont find it to be particularly ugly and it solves the problem.
      • Or, you could just crank up the warning level on your compiler to something suitably high, which will warn you when you do an assignment inside a conditional... and end up code that (IMHO) is much more readable. I've always considered the constant-on-the-left coding style to be an abomination of readability.
    • Gcc doesn't pick this up with an unreachable code warning, but it really should, since the test will always fail (since the uid-setting expression is always false).

      Gcc's sanity-check-for-use-of-assignments-for-equality-t ests-in-loops doesn't pick it up either (I think that only handles very simple cases, anyway.)

      Splint flags it as a boolean expression containing a non-boolean value, but unless you are an exceedingly anal coder, you probably have this warning off.
      • Gcc's sanity-check-for-use-of-assignments-for-equality-t ests-in-loops doesn't pick it up either

        It won't, mainly because doing anything more complex could raise false alarms for what should be legitimate statements (e.g. if (ptr=fgets(buffer, 80, stdin)) { /* ... */ } )

        GCC also allows including parenthesis to supress the check. Any experienced programmer would detect such holes, especially in the case of the Linux Kernel where there is a team dedicated to ensuring that changes are reviewed.

        The only thing

    • While the parent posted a good link to the thread, it may have been more appropriate to post a link to the start of the thread [iu.edu] rather than the near end.
  • Important contest (Score:3, Insightful)

    by jurt1235 ( 834677 ) on Sunday September 18, 2005 @11:37AM (#13589897) Homepage
    Does anybody remember the about 1.5 year ago event when a programmer managed to smuggle malicious code into the linux kernel?

    Virus writers and script kiddies are not a worry for this kind of code writing. The programmer you hire to write that AJAX extention to your website is also worth to worry about. This contest just shows how it is done.
  • by lelkes ( 884952 ) on Sunday September 18, 2005 @12:28PM (#13590098)
    It would be extremely important to use coding standards which make wrong code look wrong. Not only that it would be more difficult to inject malicious code, but if somebody made mistakes, it would be really easy to discover it.
    Joel has a great article [joelonsoftware.com] on this.
  • by account_deleted ( 4530225 ) on Sunday September 18, 2005 @12:42PM (#13590148)
    Comment removed based on user account deletion
  • Corewar veterans (Score:4, Interesting)

    by lastfish ( 246549 ) on Sunday September 18, 2005 @01:15PM (#13590284)
    Joonas & Paul are both Corewar veterans being respectively co-authors of Son of Vain (Joonas P & Ian Oversby) top of the all-time hall-of-fame and nPaper II (Paul V-K & John Metcalf) dominant paper of its time.

    Good practice for writing obscure, but useful, code.

    I'd give clickable links but fear for these sites under load.

    www.corewar.info/
    www.corewar.co.uk/94nophof.txt

     
    • by pkhuong ( 686673 ) on Sunday September 18, 2005 @02:00PM (#13590521) Homepage
      John's a corewar god (all that 6502 assembly probably has something to do with that ;), so nPaper is nearly all his: the constant twiddling (by hand!), the QS, etc. All I did was basically write the framework for the paper; the only non-standard parts were the attack engine and the djn at the end of the timescape component... and I believe the djn was removed, because, even though it was more aggressive, it was effective than a checksum with a jmz. Read CoreWarrior #.. erh. I think it was it the high 70s or low 80s. John describes the process of optimising a newbie's paper (nPaper), all by hand (He might have used some BASIC scripting :).

      Even now that we have evolvers throwing tons of computing power at a relatively small search space (nano), John submitted something that rocketted to 1st place and manages more than 50% wins. Again, the dude is a corewar genius.

      Paul(-Virak) Khuong

      PS, note the position of the dash
  • Great. The first prize is "Belgian Style" beer ... from a brewery called "Ommegang".
  • Ken Thompson... (Score:5, Informative)

    by Sam Nitzberg ( 242911 ) on Sunday September 18, 2005 @03:12PM (#13591001)
    It's not exactly the same thing, but the most powerful and clever C code example with an 'underhanded' purpose must be Ken Thompson's classic...

    Reflections on Trusting Trust
    http://www.acm.org/classics/sep95/ [acm.org]

    Other interesting papers that come to mind include Tom Duff's on Unix viruses, as well as McIlroy.

    Sam

    sam @ iamsam.com
    http: /www . iamsam . com
  • Seriously ... this was about creating code to fingerprint images. They are not creating Üb3r1337 w0rm 3xpl0i7z here.

    The "hiding the code"-part is relevant in open-source systems, and I can think of a ton of valid uses for this kind of "evil" technology. Hell, I'd be glad if some kind of function was avalible in GIMP.

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Working...