FAQ

Who are you?

I am a professor at Binghamton University, specializing in information security. I’ve been running (and funding) the Underhanded C Contest since 2005; it is based on my own interest in modern problems in deception and counterdeception.

The Binghamton University ECE department has a considerable emphasis on information security, specializing in certain deception problems: virus detection, DDoS detection, and covert channels (steganography.)

The Nuclear Threat Initiative (www.nti.org) is a nonprofit, nonpartisan organization working to strengthen global security by reducing the risk of use and preventing the spread of nuclear, biological, and chemical weapons. We are collaborating this year to focus on a security issue in nuclear treaty verification: using technology that must be trusted, and possibly jointly designed, by multiple nations.

Why?

The contest was initially inspired by Daniel Horn’s Obfuscated V contest in the fall of 2004 (note: the original page is long gone, and this link goes to a snapshot from archive.org). The object of that contest was to write a simple program to count votes, that somehow miscounts the votes on election day. I was greatly impressed to see how even a short program to simply count characters in a text file can be made to fail, and fail only on one specific day, so that the bug isn't noticed in testing.

There have been real-world examples of software bugs that allow malicious functionality, and which may have been committed on purpose. Part of the purpose of this contest is to identify underhanded tactics, and to explore what they can do and what makes them possible.

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.

Are you encouraging people to do evil things?

No. Security research typically involves thinking like an adversary to root out vulnerabilities. We are encouraging people to expose ways an adversary may sneak something into a computer program, and we hope that this may ultimately be helpful to secure software development.

Wait, is this year's contest about Iran? Is this some kind of statement about the Iranian nuclear deal?

No. This contest is not based on any specific current events or any specific nuclear agreement.

This year's challenge is based on a broad and fundamental issue in treaty verification with jointly developed technology. Problems of this sort go all the way back to the late 1970s, when Gustavus Simmons found a potential vulnerability in the system jointly developed by the US and USSR to implement part of the SALT-II treaty. This led to Simmons's seminal work on subliminal channels, which laid the foundation for modern steganography.

Is that deadline going to be strictly enforced?

This year, yes. For this year's contest we are proceeding according to a calendar in order to synchronize our contest with a second stage contest.

For the 2015 contest, what sort data am I going to be comparing?

You can get some idea of what gamma ray spectra look like through a Google Image search. In the challenge problem, the spectra are pretty abstract: there is no fixed scale for the x or y axes of the spectrum, you're just given two double arrays of the same length, along with a global baseline array that you may or may not use.

Can I use C++ instead of C?

If you actually want to subject yourself to something like that, then sure. No COBOL, please.

What compilers/platforms/etc can I use?

Whatever we can dig up, but we are most impressed by general submissions that work under any compiler or platform.

What if my code is platform-dependent? Will I lose points for that?

If the underhanded behavior only occurs on certain platforms, just let us know in the documentation.

You won’t lose points if your solution utilizes something hardware-specific like stack smashing. Indeed, the reason this is the Underhanded C Contest rather than the Underhanded Java Contest is that C offers plentiful opportunities to mess everything up at the hardware level.