Underhanded C Contest announces winners

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

Comments

Re:I'm still fond of this one

[Anonymous Coward]

This one almost made it into the Linux kernel.

It *did* make it into the kernel for anyone using the BK-to-CVS gateway.

Re:Will Code For Beer

[jkfresh]

It's not really funny if you are an alcoholic.

http://www.aa.org/

Re:Important contest

[Anonymous Coward]

Sorry to nitpick, but I think it's an important distinction. The malicious code did not actually make it into the kernel, but was caught beforehand.

Re:Will Code For Beer

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

Re:I'll tell you what's underhanded

[RAMMS EIN]

``Your web browser has a C interpreter built in?''

No, but it probably relies on lots of helper software to handle certain file types. This helper software is probably written in C or C++, and probably contains exploitable vulnerabilities. For example, your system might be compromised if the "archive" is actually an image file which your browser will try to display, using a library which contains a vulnerability which the image exploits to execute arbitrary code on your system. This may sound looney to you, but it wouldn't be the first time it actually happened.

Runtime code generation

[pkhuong]

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.

Re:Runtime code generation

[ultranova]

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 compiled and where they are located ? Simple - you implement a linked list entirely on stack. Simply have another function, which allocates a single element in the stack, links it to the previous one, and then calls the compiler function, giving it a pointer to tell where it left (passed by the compiler function to the datastore function). Of course, you'd also need to pass the pointer to the start of the list as a parameter to all of these functions...

Anyway, the point is that it would be horrendously complicated, it would be horrendously inefficient, it would be extremely easy to break unintentionally, and it would make implementing security features difficult for the afromentioned reasons - but it would be possible. In other words, it's just the way Microsoft would do it ;).

Real fun begins if you want to allocate all the objects generated by the runtime on stack too...

Re:I'm still fond of this one

[jnf]

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.

Re:Important contest

[Anonymous Coward]

Sure do.

Re:Will Code For Beer

[anagama]

Actually, what you describe is "positive punishment" (apply negative stimulus in the presence of a certain bahavior -- like a spanking for swearing). "Positive" is not used in the "good/bad" sense, put in the "plus/minus" sense.

Negative reinforcement is a reward that occurs by subtracting an adverse stimulus from the environment. For example, Fridays are a form of negative reinforcement -- the withdrawal of a negative stimulus (work) is rewarding, makes people feel good/relieved, and thus, people come to really like Friday afternoons. http://en.wikipedia.org/wiki/Reinforcement#Positiv e_vs._negative

Re:I'm still fond of this one

[Tim C]

It's not that assignments aren't allowed in if statements, but that Java has boolean types. So while a statement like i = 0 does return 0 (as in C), unlike C 0 is not false, it's an int, and so if (0) is a compile time error.

You can still do things like if ((line = in.readLine()) == null) of course

Re:Important contest

[BobaFett]

The register article is a bit alarmist, at least compared to the response Linus gives in this thread : http://www.ussg.iu.edu/hypermail/linux/kernel/0311 .0/0621.html

Ken Thompson...

[Sam Nitzberg]

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/

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

Re:I'm still fond of this one

[Anonymous Coward]

In C, a null/void pointer is technically (void*)0, but it's also specified to be equal (==) to zero. Any compiler that does not treat it as zero in boolean context (read integer context, because C doesn't have a boolean type) is not standards compliant. What you may have meant to say is that (void*)0 may not actually be on page 0 because the compiler /architecture is free reserve any spot it wants for the null pointer.

Meanwhile, the preprocessor symbol NULL is typically defined as 0 in stdlib.h, but any program is free to define it as it wishes. (Note that if you were to do so, you would create a LOT of frustration for the other coders on your team. ;)) Also, I've seen newer (usually C++) libraries use #define NULL ((void*) 0). C++ has better type management that allows it to distinguish between 0 and (void*)0, but they're still equal. ;)

However, this is all beside the point because I wasn't talking about C or C++. I was talking about my preference for dealing with values in boolean context. This lead to a mention of my language, which has a null type with exactly one value: null. In my language, null is not equivalent to zero unless you do some typecasting (e.g. null != 0, but (int)null == 0 and (bool)null == (bool)0).

Re:Bill Gates Entry

[homesteader]

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.

Re:I'll tell you what's underhanded

[Threni]

Most of the archive (in .tar format) is a picture of a train. I don't understand. Why not just post the results a text on a html page? Too easy?