The First Annual Underhanded C Contest

Xcott Craver writes "We have just announced a new annual contest, the Underhanded C Contest, to write clear, readable, innocent-looking C code that implements malicious behavior. The object is to hide evil functionality that survives visual inspection of the source. The prize is beer."

Re:This will work

[AnusesCheeses]

You mean like Hitler's infamous Beer Hall Putsch [wikipedia.org]?

Re:What are the legal ramifications of this?

[anthony_dipierro]

The authorities start a contest such as this, an unsuspecting programmer submits a malicious program, and he or she is arrested and charged with a variety of computer crimes.

What computer crimes would be broken?

Frankly, I won't participate in this contest considering the current legal state of America.

No, you won't participate because of yor current state of paranoia over the legal state of America.

Re:Indeed. This could be a field day for Java and

[CyricZ]

And like I said, do it in Java instead. That'll make it a real challenge, since the designers of Java made an effort to make it difficult to write malicious code in the first place. The point isn't that the code will look valid, but rather that it will perform malicious duties, which is something that is a challenge in Java, but easily done in C. Making it look valid is just an additional challenge for both languages.

Story is just plain bad

[typical]

Everyone knows that it is possible to write malicious code in C. That's just because C gives you the near utmost control over your system, and does not discrminiate based on human emotions like "good", "bad", and "malicious". Perhaps a better idea would have been to try to write malicious code in a language such as Java, which tries to prevent a programmer from writing such code. That would be a real challenge.

Yeah, I just flip the "+good +bad -malicious" flags on javac when I want to trust code. Come on, that's ridiculous.

This is not a hard task, but it's kind of stupid, on the order of "who can break into the most computers today" (I dunno, who can run nmap the longest?)

There are so many *interesting* things that could be done as a programming contest, and the submitter chose something that's a pain in the ass for other people, doesn't really challenge the brain ("shortest version of X"), and can't be used for much other than bogus arguments that "C is dangerous" or the obvious card, "Open Source is insecure" (you can look at the much larger sample set of SourceForge and the lack of Trojans implanted and later discovered).

The number of *interesting* security stories that could have challenged people and been useful is legion. "Can we have a system that is unbreakable and does X", (followed by the inevitable followup posts where people punch holes in the design) or other things. You could have asked "How can OSS projects avoid allowing malicious code being sumitted?", which would have started an interesting set of threads from people who work on proof-carrying code, would have taught readers something, and maybe provided improved security for the world at large. Instead, we're going to see a handful of bad, obfuscated C, and a bunch of halfassed arguments against C and OSS, neither of which has much connection with reality. There will be some language arguments, where someone says "we should use [LANGUAGE_WITH_BOUNDSCHECKING]", some security guy that will point out that this doesn't begin to avoid stopping malicious code, someone will make some stupid arguments about how their favorite OS is more secure than anyone else's, we'll get some rehash of NX features that have been done time and time again on Slashdot...seriously, goddammit. The day someone makes a knockoff of Slashdot that's a bit more computer-science oriented and isn't solely aimed at producing the same tired old trolling every day is the day I jump ship.

Diebold

[jay95]

I nominate Diebold!
Now if only we can get them to enter their code in the contest...

Why?

[simulacrum25]

Hacking was never about malicious behaviour, it was about learning and understanding. Granted, much of what one learned could be applied in malicious ways, but that wasn't the goal. Coding contests whether they be geared towards obfuscation or speed are still learning endeavors.

Who is behind this and what is their motivations? What will they do with the ideas submitted in this contest? In a day of professional computer hackers, this is not a contest to have.

Re:It's a bad idea

[Catamaran]

C gives you just enough rope to hang yourself.

Java gives you a polished floor on which you can slip and break your neck.

C++ gives you a thermo-nuclear device.

Mod Parent Up!

[Anonymous Coward]

My original post was to be along the lines of 'how long before this kind of technique is used to poison Open Source?'...

Tin foil hat on, for sure. :)

Re:Why?

[Nf1nk]

To find subtley malicous code in an open source project, we first must know what it looks like. Having contests like these creates a sample base of dangerous code and clever tricks to read and learn from.
It is sort of like the computer version of a bomb squad.

Re:Indeed. This could be a field day for Java and

[argent]

That'll make it a real challenge, since the designers of Java made an effort to make it difficult to write malicious code in the first place.

Actually, that's not really the case... not for the kind of "malicious code" that they're talking about here. They're not talking about "getting out of the sandbox", they're talking about "hiding information in the output". It's actually a lot easier to hide this kind of "malicious code" in an object-oriented language because you can play games with the namespace.

Re:There you programmers go again...

[bennomatic]

No, not seriously. I was just reading an article on the Patriot Act, though, and was thinking about how the masses--the same ones who are willing to accept that using BitTorrent is equivalent to terrorism--might see this sort of endeavor.

Re:in other words...

[grammar fascist]

On a more serious note - they should rethink their prize. Not everyone drinks beer, and there are plenty of talented programmers who avoid it completely. In fact, the ones who do probably have more working brain cells to throw at the problem.

Yes, I know that must come as a shock, and most people here probably won't believe me...yet it's true.

(And just to head off the inevitable nutcase looking for a Score:5, Funny: no, replacing the prize with free pr0n isn't going to cut it. :p)

New law.

[elucido]

Anyone who has to make use of Godwins law obviously must agree with Hitler. Godwins law is equal to censorship. Just because you dont discuss Hitler, the nazis, fascism, etc does not mean it suddenly ceased to exist.

The new law which evolves beyond godwins law to allow people to discuss hitler shall be called what? Slashhdot can think of a name right?

You're just not used to it.

[Tyler Durden]

Problems: difficult to compile

A picky compiler is a blessing, not a curse. It's much easier to identify and fix compile errors than run-time errors.

difficult to convert to better languages (thank you preprocessor)

Meaningless troll.

encourages obfuscation

Unless the compiler is literally holding a gun to your head, this is meaningless. In C you have nearly limitless control to write your code the way you feel is clearest. If it came out obfuscated then you have nobody to blame but yourself.

some constructs are clearly tacked on and/or poorly implemented (switch), arbitrary nonorthogonality (struct, parens and brace usage, pointer/array declaration), shitty strings.

Tacked on? If you don't like the way constructs are set up then fine, that's your opinion. But if you read The C Programming Language you can tell that every single construct was scrutinized over for the proper balance of efficiency (why it makes sense to pass array parameters as pointers and structs as copies) and consistency (why data types are declared the way they are. Declaration and use of data is made to match.) Do you honestly believe the creators/first users of C, some of the greatest programmers who ever lived, really said, "Ahhh, fuck it. Let's just throw something together," when designing their own programming tools?

Most people who don't like C are really just saying they don't like low-level programming because that's what it was designed for, and that's what it's perfect for. Too many newbie programmers get used to some modern, flash-in-the-pan, all-things-to-all-people languages and when they are faced with the challenges of low-level languages rashly conclude that it's the language's fault they're having problems.

C is the perfect language for the job it was designed for. The same cannot be said for most more modern languages.

Re:C is an awful language

[jejones]

Well...

C is good for what it was first used for: writing Unix. At least initially, it was mimimalistic; orthogonality took a back seat to ease of implementation. (See Gabriel's classic essay [jwz.org] for details.)

(It's certainly not flawless. Any language that needs a utility like cdecl to make declarations understandable has problems, and there should've been a Boolean type from the beginning. It would be nice if char (which should be whatever represents a glyph on the target system) weren't conflated with short short int. Basically, if C were in your back yard, it would be declared an "attractive nuisance.")

I think the authors of The Art of Unix Programming wisely recognize that C, like any other tool, should be used only where appropriate. (Sorry if that's tautological, but I can't think of a better way to put it.)

Re:So are you very, very good or very, very bad?

[anno1602]

Writing code of that quality that looks like it does what it's supposed to do, while actually doing something subtly different, sounds like a very difficult challenge to me.

Programmers do that every day. It's called a "bug". Now, doing something subtly different and controlling what the subtly different thing actually is, that is a challenge.

Re:Why?

[iluvcapra]

Methinks the poster refers to this [iu.edu], wherein some as yet uinidentifed party inserted a line into the kernel sources on the CVS repository.

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

if these random options are passed, and the uid of the "current" struct is 0, then do the block, right? 8^o Fortunately, some sharp programmers caught this before those files got integrated back into the kernel, but who knows what the future may bring.

Re:You're just not used to it.

[Tyler Durden]

No flame. There are problems with C, I'll grant that. I don't know if the problem with the pre-processor is that it's too powerful or by convention it is depended on too much. Unfortunately, in some places it requres #defines where a const variable would be better. That and macros for functions where a simple inline keyword would help tremedously. Of course, these have been addresses in C++ and (I think) C99.

I'm not sure about strings. With the really low level stuff like OS development, I can see the case for just contiguous characters terminated by a NULL character. Otherwise it's not so hot.

But I still maintain that C works extremely well for what it was created for. I mean, how long did it take before it needed to change as opposed to C++ that becomes more complex by the hour? (I really have a love/hate attitude towards C++. I think it's a horrible language to match the needs of a horrible world. Then again, I should look more into Objective C.)

C99 addresses a lot of valid concerns with the language, though. That and D sounds promising.

Re:You're just not used to it.

[Dun Malg]

2. Strings. There is *no* excuse for C style strings. Is it really such a problem to create a type that has a length encoded into the start?

Clarity. All the data types in C are intended to be clear. It's only a single step up from assembly, really. C handles strings the same way assembly does: it eats bytes sequentially from an array, and it's up to the programmer to tell the program when it's had enough. Data handling in C is a virtually transparent veneer of abstraction from pointer arithmetic. A string data type with length encoded into it would require special handling, and C just don't play that game. C is all about pounding raw bytes and twiddling naked bits. If you want fancy meta-data, you're using the wrong language. Try C++ of Java.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:You're just not used to it.

[syle]

. Strings. There is *no* excuse for C style strings. Is it really such a problem to create a type that has a length encoded into the start?

I think you're confusing C with a high-level language. It doesn't give you lists, associative arrays, or strings because those are high-level data types and C is a low-level language. Your complaints are like saying the biggest problem with a car is you can't drive it on water -- they display a fundamental misunderstanding of the subject.

Re:Attack the Compiler

[LionKimbro]

Yes, quite right.

I guess the thing is: What we're really concerned about here, (if I may project a little,) is voting software.

In those cases, they're probably not going to say, "download the compiler from a random site on the net." In fact, it's probably going to be very hard to control the people who compile the software, and even harder to control the people who compile the compiler. At some point, somebody's going to get the compiler, and they're going to get it from some specified place.

If it's a secret place, then the vote is determined by whoever controls that secret place. If it's a public place, well- that's something to think about.

Maybe we should have a Federal list of 100 places to get the compiler from. Or a thousand places. However it is done, we want to make it more expensive to buy the vote than the vote is worth.

Re:You're just not used to it.

[csirac]

I think it is very odd you can't believe we're still using C in operating systems. What the other language are we going to use for this task?

Are you really going to want to wait 100s of milliseconds for a garbage collector to run at arbitrary intervals in your carefully word aligned DMA transaction code that needs to run within a matter of microseconds? And how exactly is Python, LISP, or any other interpreted/dynamic runtime compiled language going to be used to write a task scheduler or memory managment system worthy of being used in an OS kernel or embedded MCUs with barely 16KiB RAM?

I think you're quite bitter about having to use C for writing applications, which I can perfectly understand. As for what C is actually MEANT for, it does the job quite well. And yes, the preprocessor issues suck, and it would be nice to have Pascal strings, but there really is no alternative to C that I have seen for low-level programming. It makes computer science purists who think everyone should program in Haskell or LISP feel dirty, but it does the job very well. It sure beats writing directly in ASM.