Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming Security

Winner of the 2015 Underhanded C Contest Announced (underhanded-c.org) 48

Xcott Craver writes: The Underhanded C contest results have now been announced. This time the contest challenge was to cause a false match in a nuclear inspection scenario, allowing a country to remove fissile material from a warhead without being noticed. The winner receives $1000 from the Nuclear Threat Initiative.
This discussion has been archived. No new comments can be posted.

Winner of the 2015 Underhanded C Contest Announced

Comments Filter:
    • by Anonymous Coward on Wednesday February 03, 2016 @02:45PM (#51432813)

      Does any program compile with -Wall -Werror?

      • by Anonymous Coward on Wednesday February 03, 2016 @03:07PM (#51433067)

        yes? mine do. Always.
        if there's a warning you fix it. Or if it's unfixable you suppress that specific warning.

      • by raymorris ( 2726007 ) on Wednesday February 03, 2016 @04:10PM (#51433629) Journal

        Yes, -Wall is good way to find code smells.

        For obfuscated code, I suggest -Larry -Wall.

      • Re: (Score:2, Interesting)

        by Anonymous Coward
        It has been a requirement in all of my jobs. I work on things where many lives are dependent on correct function [wikipedia.org]of the software.
      • That's like asking if "Has anyone ever gotten an A in a class?"
      • Hm, compile? Perhaps!
        Does it run, too?

  • Linus Akesson? (Score:4, Interesting)

    by wardrich86 ( 4092007 ) on Wednesday February 03, 2016 @02:34PM (#51432703)
    As in the chiptune dude? Can anybody confirm it's the same guy?
  • This time the contest challenge was to cause a false match in a nuclear inspection scenario, allowing a country to remove fissile material from a warhead without being noticed.

    That's a highly specific thing ... who funded this again? :-P

    • by Striek ( 1811980 )

      The Nuclear Threat Initiative [nti.org].

      This year's challenge (detailed below) is a real-world problem in nuclear verification, sponsored by and designed in partnership with the Nuclear Threat Initiative (http://www.nti.org/), a nonprofit, nonpartisan organization working to reduce the threat of nuclear, chemical and biological weapons.

    • The Iranian government.
  • Do not use common function names when defining new function. This would be caught simply by insisting that the function is already named, and thus being sent back the the programmer to rename it something else.

    • by Anonymous Coward
      Um, what? It has nothing to do with the function name.
      • This header file defines float_t as double precision, although by default math.h defines float_t as single precision.

        Sorry. Technically float_t is a type, and defined as single precision. double_t is the correct type for double float

        Regardless, redefining the float_t to being double is the problem, when it is already defined as something else. Sending back for a fix would solve the problem, rather than redefining what float_t means. Of course, you can remain pendantic and not get the point I was making. It is solvable, by sending the code back for revision, to remove the problematic re-defining of the type. In this case,

        • Re:Fixable - Easily (Score:4, Interesting)

          by Actually, I do RTFA ( 1058596 ) on Wednesday February 03, 2016 @04:38PM (#51433903)

          redefining the float_t to being double is the problem, when it is already defined as something else

          It's not being redefined. Because of the way the C compiler works, it has different values at different points of compilation, but never does one definition get overwritten by another one. (Analogous to many wrong API based errors). The fact you would think it's checked against by the compiler makes this cleverer, because you'd expect the machine to throw a warning if it was actually redefined.

          And float_t is supposed to define (at least as wide as a float) the commonly used float type in this environment. According to the given spec, the min float type was supposed to be a double. If that were consistently included in all files, it would have actually triggered errors if you ever used a regular float function. The problem was not enough redefining

          • My understanding if float_t means one thing here, and another thing there, then it isn't defined correctly. Standard Math.h files expect it one way, changing that in one place, but not passing that change on to every other possible place is problematic, and as a programmer SHOULD cause flags. Compilers don't care, as you stated.

            It should have been flagged somewhere by someone or something. Because it wasn't, looked innocuous and has a potential for HUGE problems down the road. Just because something is allo

  • by OffTheLip ( 636691 ) on Wednesday February 03, 2016 @02:38PM (#51432735)
    Now we know what really took place at Volkswagen and the rigged emissions. Underhanded C!
  • typedef double float_t;
    Nice solution, but I'm not sure it would not get detected with proper coding standard, peer reviews, and testing. But it would depend on a human factor. Plus compiler would likely give a warning for overriding a typedef.

    • by Xcott Craver ( 615642 ) on Wednesday February 03, 2016 @02:57PM (#51432963)

      Hi,

      I didn't mention it on the page, but the C file that #includes that header doesn't #include math.h, so there is no typedef overridden. A second C file #includes math.h without #including that header.

    • They carefully didn't include math.h (where float_t is normally defined) in the same file (but did elsewhere, to create the error.)

      Even better, the floating point precision was defined in the spec as being a double. Therefore, the error looks benign. Certainly, a quick code review may thing it's actually setting the precision of the math library.

      And, if discovered, it looks super-innocent.

      This kind of solution is why I didn't enter. I had some ideas (all based around NaN poisoning), but knew that I didn't

      • by Anonymous Coward

        I love this one. And, as you point out, it is the fact that it appears, if discovered, as a simple coding error that make it so elegant.

        If it was caught, about all it would cause is a comment from your boss in the next one-on-one "Hey, dude, be more careful reviewing your code - spend more time if you need to" rather than a visit by the FBI or NSA (well, except maybe to hire you if they got wind of the bug and thought you were doing it "because you could", not "because you cared").

        • by tgv ( 254536 )

          Exactly. The people commenting ITT that "it's easy to fix" or "the compiler should give a warning" or whatever miss the point entirely. This is sneaky use of a language feature.

  • by T.E.D. ( 34228 ) on Wednesday February 03, 2016 @03:36PM (#51433355)

    I've enjoyed these over the years. My personal favorite was the "English to Pig Latin" translator whose source code looked like ASCII Art for a pig [github.com].

    But really, if you can do stuff like that, you can do pretty much anything. So what's the point, really? Where's the challenge?

    A much more interesting contest would be to write C code that's simple and understandable. Yes, I said it, simple and understandable and in C. There's a challenge to bend the minds of the world's greatest programmers.

    • by Actually, I do RTFA ( 1058596 ) on Wednesday February 03, 2016 @04:32PM (#51433849)

      You're thinking of the obfuscated C contest. That involves C code that operates correctly, but looks like junk (even under scrutiny). This is the underhanded C contest. This involves C code that looks correct (even under scrutiny), but operates like junk.

      • by T.E.D. ( 34228 )

        Not quite. The IOCCC entries are just supposed to be really misleading (iow: "obfuscated") in what they actually do. If you can't figure it out at all, that works. If you think you know what it does, but it does something else, that's even better.

        The underhanded C contest just takes this principle, but applies it to security specifically.

        • To be fair, many entries boil down to precompiler shenanigans. Impressive, but not particularly interesting.

          The underhanded C contest is, in my opinion, more interesting. Obfuscating something into a mess that is impossible to understand is relatively easy. Writing code that passes a decent examination of the source but is actually designed to fail in a very specific way is much harder.

  • by epine ( 68316 ) on Wednesday February 03, 2016 @09:42PM (#51436075)

    The stupid thing is that C++ name mangling [wikipedia.org] would already catch this problem at link time, and every modern C/C++ compiler already has code to support this, except that it's only activated for the much loved/unloved function overloading.

    If GCC/clang in C mode generated mangled names into object files when compiling C programs (as purely informative records), the linker could diagnose this kind of problem as optional linkage errors—mighty darn useful, optional linkage errors.

    This is a violation of the type system pure and simple, but one that doesn't compromise any specific compilation unit. That leaves the linker as the next line of defense, but like to keep our C linkers in dark boxes full of trust-me horse shit.

    • by T.E.D. ( 34228 )

      This is a violation of the type system pure and simple, but one that doesn't compromise any specific compilation unit. That leaves the linker as the next line of defense, but like to keep our C linkers in dark boxes full of trust-me horse shit.

      For the most part linkers aren't supposed to be language-specific. Whatever language you use (it could indeed be C, but it could easily be something else) produces an object file in the OS's standard object file format, and the linker's job is to link various object files and libraries together into an executable.

Basic unit of Laryngitis = The Hoarsepower

Working...