Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the use-it-for-good dept.

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.

48 comments

  1. wmd on credit 'weather' wizards & warloks by Anonymous Coward · · Score: 0

    they should get something?

  2. Do these programs compile by buchner.johannes · · Score: 1

    with -Wall -Werror ?

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    1. Re:Do these programs compile by Anonymous Coward · · Score: 5, Funny

      Does any program compile with -Wall -Werror?

    2. Re:Do these programs compile by Anonymous Coward · · Score: 5, Insightful

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

    3. Re:Do these programs compile by Anonymous Coward · · Score: 0

      Some of the "warning" -Wall checks and calls out are asinine. There not worth the time to "fix" just to make the compiler happy.

    4. Re:Do these programs compile by luis_a_espinal · · Score: 5, Insightful

      Some of the "warning" -Wall checks and calls out are asinine. There not worth the time to "fix" just to make the compiler happy.

      I cannot remember a concrete, very specific case from ages past where this was true. But in general, and after seeing a ton of code, if you start from the beginning with -Wall -Werror and don't let that shit go, it goes a long way towards maintainability.

      Additionally, the moment you let that discipline go, things begin to go to shit. And before you know it, you have your compilation logs fulled with warnings that you cannot turn off because of the off change one of them might be relevant, and no way to go back and clean that shit up because the technical debt is too huge.

      I hate working with projects were -Wall -Werror is not the norm for the bulk of source code. In the general case, warnings are latent errors and you might as well squash them without mercy before the creep out of your control.

    5. Re:Do these programs compile by Anonymous Coward · · Score: 0

      Too bad your code will not compile with older versions of gcc now which issues wrong warnings.

    6. Re:Do these programs compile by Anonymous Coward · · Score: 1

      I believe the submission is also something that can be statically analysed though. It's converting to a pointer of a different type without a cast. It's still a crafty entry but very easily detected. Perhaps there is a cast not shown because of the excerpt.

    7. Re:Do these programs compile by Anonymous Coward · · Score: 2, Insightful

      Some of the "warning" -Wall checks and calls out are asinine. There not worth the time to "fix" just to make the compiler happy.

      Dude, when the folks who wrote the compiler that you're using to turn your source code into a runnable program took the time to do extra work to warn you that your seemingly-correct source code does something dodgy, you'd probably be best served to listen to them.

    8. Re:Do these programs compile by Anonymous Coward · · Score: 2, Interesting

      It has been a requirement in all of my jobs. I work on things where many lives are dependent on correct function of the software.

    9. Re:Do these programs compile by Anonymous Coward · · Score: 0

      I would have pointed out overloaded functions where some versions do not require all parameters, resulting in an unused variable warning that you want to keep for stylistic reasons, but that was before I discovered (void) varname to remove said warning. So yeah, I'm drawing a blank.

    10. Re:Do these programs compile by Anonymous Coward · · Score: 0

      And suppressing it is allowable for the purposes of this argument?

      Kind of sounds like saying, "well I can't fix this so I'll just put some duct tape over it."

    11. Re:Do these programs compile by Xcott+Craver · · Score: 4, Informative

      Hi,

      In the winning entry there is no cast or "conversion" per se. It has one C file that calls a function and another C file that implements the function, with a mismatch between the types of the call and the implementation. Neither file by itself is performing any conversion or doing something wrong that can be caught by static analysis; the bug is caused by a mismatch between the code in two object files. This would only be caught by a tool that would examine the two files together, but it would not be caught by the compilation of either part.

      We've actually seen a number of past entries that used this same basic trick to mismatch a call and an implementation. A previous winning entry managed to redefine the time() function as time_t time(void) instead of time_t time(time_t *ptr), avoiding a compiler warning by using the extern keyword. That's a neat trick because barely anyone uses the argument to time(), and after writing t=time(NULL) hundreds of times, it's easy to completely miss a call like t=time(). This caused a call to time() with the wrong number of arguments, so that another variable on the stack was used to hilarious effect.

    12. Re:Do these programs compile by TsuruchiBrian · · Score: 1

      That's like asking if "Has anyone ever gotten an A in a class?"

    13. Re:Do these programs compile by Anonymous Coward · · Score: 1

      > Some of the "warning" -Wall checks and calls out are asinine.

      [citation needed]

      Besides, last time I checked, [anonymous coward] ain't a compiler expert. I *must* know.

    14. Re:Do these programs compile by Anonymous Coward · · Score: 0

      Binutils does.
      Strangely, GCC does not.

    15. Re:Do these programs compile by angel'o'sphere · · Score: 1

      Hm, compile? Perhaps!
      Does it run, too?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    16. Re:Do these programs compile by T.E.D. · · Score: 1

      Some of the "warning" -Wall checks and calls out are asinine...

      I cannot remember a concrete, very specific case from ages past where this was true.

      If you are using the Microsoft compiler, there are rather a lot of warnings along the lines of "I see that you are using a POSIX standard routine. You really should instead consider using our incompatible variant of it (incidentally tying your software to our platform) because F.U.D. Woggity boogity!"

      In C++ template programming I also have started seeing a rather lot of "unreachable code" warnings due to code that will never be executed for one specific instantiation of a more generalized template. You could go make yourself a specialization for that one instance that you just found and copy all the code except the unreachable part to get rid of the warning, but that would be kinda stupid.

      But even in these cases, I totally agree that you are much better off compiling with -Wall and pragma-ing away the specific warnings (at the lowest scope possible) after first examining that specific occurrence and making sure its not a problem. Back in my Ada days most of those warnings would be full-blown errors. Developers would eventually learn that the painful compiler experience prevents a far more painful debugging experience. Instant gratification in software, like in life, tends to turn out badly.

  3. Linus Akesson? by wardrich86 · · Score: 3, Interesting

    As in the chiptune dude? Can anybody confirm it's the same guy?

    1. Re:Linus Akesson? by Infiniti2000 · · Score: 4, Informative

      Seems very much like the same guy. He posted chiptune on his site and also had some past underhanded entries there. Presumably, he's just not updating (or updated) for this last entry.

    2. Re:Linus Akesson? by Anonymous Coward · · Score: 0

      it seems.
      He also a wizard with micro controller stuff

    3. Re:Linus Akesson? by JustOK · · Score: 1

      Just don't let him near a BeOS R5 on a dual G3 box when all four MIDI ports are active

      --
      rewriting history since 2109
    4. Re:Linus Akesson? by wardrich86 · · Score: 1

      For the past few years this guy has been increasingly becoming a hero of mine. The stuff he does absolutely blows my mind. If we could choose our own mentors, he'd be up near the top of my list for sure.

  4. Wow ... by gstoddart · · Score: 1

    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

    --
    Lost at C:>. Found at C.
    1. Re:Wow ... by Striek · · Score: 2

      The Nuclear Threat Initiative.

      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.

      --
      "Government is like fire; a handy servant, but a dangerous master." -- George Washington
    2. Re:Wow ... by bugs2squash · · Score: 2

      The Iranian government.

      --
      Nullius in verba
  5. Fixable - Easily by Archangel+Michael · · Score: 0

    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.

    --
    Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    1. Re:Fixable - Easily by Anonymous Coward · · Score: 1

      Um, what? It has nothing to do with the function name.

    2. Re:Fixable - Easily by Archangel+Michael · · Score: 1

      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, using double_t instead of redefining float_t .

      http://pubs.opengroup.org/onli...

      float_t
              A real-floating type at least as wide as float.
      double_t
              A real-floating type at least as wide as double, and at least as wide as float_t.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    3. Re:Fixable - Easily by Actually,+I+do+RTFA · · Score: 3, Interesting

      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

      --
      Your ad here. Ask me how!
    4. Re:Fixable - Easily by Archangel+Michael · · Score: 1

      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 allowed, doesn't make it right. Lots of huge bugs are created that way.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  6. Volkswagen, is that you? by OffTheLip · · Score: 4, Funny

    Now we know what really took place at Volkswagen and the rigged emissions. Underhanded C!

  7. So winner's solution overrides standard type by postmortem · · Score: 1

    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.

    1. Re:So winner's solution overrides standard type by Xcott+Craver · · Score: 4, Interesting

      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.

    2. Re:So winner's solution overrides standard type by Actually,+I+do+RTFA · · Score: 2

      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 have a clear and clever solution like this.

      Maybe next year

      --
      Your ad here. Ask me how!
    3. Re:So winner's solution overrides standard type by Anonymous Coward · · Score: 1

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

    4. Re:So winner's solution overrides standard type by tgv · · Score: 2

      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.

  8. How about an "Understandable C Contest"? by T.E.D. · · Score: 4, Interesting

    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.

    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.

    1. Re:How about an "Understandable C Contest"? by Anonymous Coward · · Score: 0

      /*angle braces don't display properly in slashdot comments*/
      #include "stdio.h"
      int main() { printf("hello simple and understandable world!\n"); }

    2. Re:How about an "Understandable C Contest"? by Actually,+I+do+RTFA · · Score: 4, Informative

      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.

      --
      Your ad here. Ask me how!
    3. Re:How about an "Understandable C Contest"? by T.E.D. · · Score: 1

      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.

    4. Re:How about an "Understandable C Contest"? by ericloewe · · Score: 2

      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.

    5. Re:How about an "Understandable C Contest"? by Anonymous Coward · · Score: 0

      How did this get marked "interesting"? C'mon, Slashdot readers. This guy is clearly confusing the Underhanded contest with the *obfuscated* contest. Well, written C is about as hard to understand than well-written code in other languages.

    6. Re:How about an "Understandable C Contest"? by T.E.D. · · Score: 1

      Didn't read the other comments, did you?

  9. -Wall yes, -Larry -Wall for obfuscation by raymorris · · Score: 4, Funny

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

    For obfuscated code, I suggest -Larry -Wall.

  10. so self-inflicted it isn't funny by epine · · Score: 3, Interesting

    The stupid thing is that C++ name mangling 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.

    1. Re:so self-inflicted it isn't funny by T.E.D. · · Score: 1

      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.

  11. The rightful winner is North Korea! by Anonymous Coward · · Score: 0

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

    Did you know the USA spent ~50M dollars to attack the DPRK's nuclear bomb programme with a modified version of Stuxnet? They failed because the computers CIA strategically placed for North Korea to buy ended up not in the uranium enrichment bunkers but in Kim's office (where they were used to review pornography in order to protect the glorious communist morals of the population).

    Thereby the award is officially assigned to the DPRK. Juche Korea!