Slashdot Mirror
The 2006 Underhanded C Contest Begins
Xcott Craver writes "The second annual Underhanded C Code Contest is live as of April 4th, and runs until July 4th. The object is to write malicious C code that looks perfectly readable and innocent under informal inspection of the source."
Windows!
Oh darn, it's not written in C.
In this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
system("c:\Program Files\Internet Explorer\iexplore.exe");Where's my prize?
--
"Man Bites Dog
Then Bites Self"
Capitalism: When it uses the carrot, it's called democracy. When it uses the stick, it's called fascism.
Why is this a good thing? I'm not a programmer, so I don't really understand why writing code that appears to be innocent, yet is really evil, help the community?
I understand about making source code available helps in a secure system, but what if that code has evil code...made to look innocent upon inspection....written into it?
I know that showing how to crack into a system, or how to write a virus actually helps in the long run as it exposes weaknesses that can and should be patched and closed. But what does having people practice hiding malicious code do for us?
Just wondering. I find this stuff fascinating....though not fascinating enough to actually learn how to do it!
"Leo Fender was in a 'state of grace' when he designed the Stratocaster." -- Paul Reed Smith
Anything similar for PHP?
I stopped using "real" languages years ago. ;)
Math is math. Regular expression is regular expression. The tools are there. The future is now.
...I'll design a media player that appears to be playing a CD when it's actually installing a root kit that creates an easy way back door for malware.
And then I'll get sued by Sony for copyright infringement.
I really liked last years task but this years, um ...
It depends way too much on things like the compiler being used, the optimization level, the actual hardware (how do they compare program run-time if the two OSes in question run on very different CPUs ?), and so on, than on actual C.
I'm sure some companies would pay *way* more than a $100 voucher for ThinkGeek for useful information like this :-)
... happen ... quickly ... on ... it.
Nice hardware/OS platform you got there. It would be a shame if something were to not
If the comparison would be Linux vs. Windows, ok. But Wine is not an OS, and thus does not qualify.
Really!
The best malicious hack is the one where you bring the code to the machine, run it, then take it away again leaving no trace.
you could learn c so you could code in something people wont hate you for using *cough* php *cough*
"I worry that some day my child will ask me, 'Dad, where were you when they took freedom of the press from the internet?
For a (past) contest targeting the specific scenario I described above, see the Obfustcated V contest, which was the inspiration for Xcott's contest. The winning entry manages to only show its bias on the day of the election itself, but not before, so that it can satisfy serious testing.
Someone's going to have to write the operating system of the future and it ain't going to be in Ruby. Or C# for that matter.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Any code that includes a patented idea could win this contest.
Looks innocent, is malicious.
Now that I'm getting PHP under my belt, do I have any reason to learn C? Isn't it Ruby time? Shouldn't everyone go LAMP beginner programmer or otherwise?
LAMP is certainly a great tool. It's very practical and useful.
As for a beginner language? Hmm. I always kind of wince when people get their programming feet wet with web-based development. There are so many issues involved with web development (browser issues, the interplay between database/server-side scripting/client-side scripting/etc) and several different languages involved (SQL,PHP,HTML at a minimum) that a beginner's head is often swimming.
It's certainly not rocket science, and if you can hack it - good for you! But I'm kind of skeptical that the best way to learn good programming practices by starting off with web development.
On the other hand, web development is fun and you can see some immediate results. Throwing an application up on the web is a lot more satisfying than writing Yet Another Linked List Implementation in C/C++ or something - something that would surely turn a lot of potential programmers off. While I'd rather see new programmers go the traditional CS route and do some learning of "the basics" in non-GUI non-web programming environments*... whatever works. Have fun!
* These environments could certainly be modern OO languages like Ruby
OtakuBooty.com: Smart, funny, sexy nerds.
It shows.
Go Python for now, keep an eye on Rubyforge. Not sure if the way Ruby is implemented (with the syntax trees rather than bytecodes) is going to be an issue or not. Also mod_ruby is implemented still kind of wonky I understand.
Isn't it likely that encouraging people to design programs in this way would lead to companies using these techniques in their own software? Say someone has a contract with Microsoft, the linux version, while being fully functional, could be made to be slower. Then someone would go and demonstrate how poor linux performanace is yadda yadda
Well, for starters you might want to use C so you can compile a program,
and create an executable. PHP is an interpreted program, that runs in a very specific environment. C is a language that is (mostly) platform independent, and compiles to a -stand alone- executable.
LAMP is a versatile Kludge. C is a language. You choose.
That sounds like most of the C code I've ever seen... or written, come to think of it...
GetOuttaMySpace - The Anti-Social Network
#ifdef WIN32
#define MSLEEP(a) Sleep(a*1000)
#else
#define MSLEEP(a) select(0, NULL, NULL, NULL, { 0, a*1000 })
#endif
void main(int argc, char **argv, char **envp) {
}
Answering my own post;
//.. process the input
#ifdef WIN32
#define MSLEEP(a) Sleep(a*1000)
#else
#define MSLEEP(a) { struct timeval tv = { 0, a*1000 }; select(0, NULL, NULL, NULL, &tv); }
#endif
{
char buf[1024];
while (waitforinput(buf, 1024)) {
MSLEEP(10);
}
}
'Cos the fifth argument is a pointer to a struct timeval, not a struct timeval. Still, it looks _somewhat_ innocent, doesn't it ?
"What could possibly go wrong?"
My sig is too lon
At the risk of being redundant... Was just configuring a PHP include file, realizing there is not standard or even accepted practice for the names and forms of include files in PHP. I remember this one C project though that had standardized on having no compiler checking on function declarations, prefering instead this giant switch statement that decided what function to call at runtime. What a nightmare. This was a "best practice". Had arrived late as a troubleshooter, took me forever to recover my senses and ask why the hell are we doing this. For applications, I would think the names and forms of things would be more standard in Ruby, will see...I like Python for its significant whitespace.
To me, as soon as the C code uses pointers, it is potentially malicious. That's one of the reason why so many people choose Java, C# or other pointer-free languages.
It's in Pascal :-).
I see a lot of utility in a contest like this. As much fun as an obfuscated programming contest is, in a day and age when our critical infrastructure, including voting machines, are running on software, it is important that we be aware of just how difficult it to assure that code does what it should.
A related contest I would like to see is a lucid programming contest. Given some small but insidiously tricky task, write a program in the language of your choice which solves the problem correctly and which is easy for someone else to understand. It would be interesting to discover which languages excel at this task and what sorts of patterns emerge when emphasis is placed on clarity.
main() {
printf("hello, world\n");
}
An oldie but goodie . . .
while (1){
status = GetRadarInfo();
if (status = 1)
LaunchMissiles();
}
Actually, the latest version of Flash I would consider an excellent starter language. It combines the ability to get stuff on the screen quickly from VB (although I haven't used that in the past decade), and, underneath the horrible deprecated AS 1, the AS 2 version supports things that I would consider good coding practices. Like typing. And being able to make classes.
But then again, the editor/compiler is expensive. And the graphics obscure the code.
Now if you'll excuse me, I get to go work with my first language (C++) some more. Yay pointer arithmatic!
Is noone talking about which OS will 'lose' (ie. the winning program will run slower on it rather than the competition) because you all assume that Windows will?
Actually, it is in C#.
http://research.microsoft.com/os/singularity/
Imagine you're a company developing applications and you get a resume from someone who won this contest. You want the best infiltrators on your team because they'd know what to look for when writing a "secure application." Just like you'd want the best "(24x02"s on your network security team... theoretically :).
...and in some circles... it's an extension of one's manhood
It's like the story of Frank Abagnale.
This message was posted using recycled electrons.
This contest is useless... it's already been won and unlikely to be outdone -- dear member of slashdot, I give you... WINDOWS!
PS. Yes, I am sick.
Can I beta test these things? =P
Time is an illusion. Lunchtime doubly so. - Douglas Adams
If you got the joke, it was close enough.
10 Print "Losers"
20 GOTO 10
Run
Just another item on my list of reasons I hate C-language. And I first started uisng C in 1977.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
#include <stdio.h>
main()
{
char stuf[80];
while(1)
{
fputs("Enter something: ", stdout);
fflush(stdout);
gets(stuf);
fputs("You have entered ", stdout);
printf(stuf);
}
}
silly (and looks innocent enough) but closer inspection will reveal nastyness...
SIGBUS @ NO-07.308
#include
int main( void )
{
printf("Goodbye, world!");
}
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
I believe the software was stolen, not purchased, so from my point of view, the answer would be a definite 'no', although with the state of legal affairs the way it is (burglar slips and sues), all bets are off.
Since it's the CIA, and in another country, I would imagine the answer would be 'no' regardless. But happily, IANAL.
In Diebold's case, I'm not willing to ascribe to incompetence that which can be explained by malice.
Personally, I'd go Occam's Razor on that issue and say that there's been a few hundred more years of mechanical voting fraud to fall back on rather than messing with software. Why do you think the dead rise again every few years to vote?
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
That was my thought, too. But then many geeks like Kjella seem to suffer from some variation of Asperger's syndrome, making them overly pedantic and humor challenged. Symptoms include hanging out on /.
Then I looked at the solutions. Two of them involved a loop with something like while(a = b) instead of while(a == b). Yes that is just one character difference, that's something that doesn't look malicious, but in fact, it's obvious. Anyone who is familiar with C knows that that is a common type of bug. I think some syntax checkers and code viewers even flag warnings on stuff like that (as they should).
Of course there were the predictable buffer overflows and stack underflow type of attacks.
Second trick, some of them mis-interpreted data from the stat structure. Good job again! That's harder to spot.
Finally, and most tricky, some of them managed to sneak in some assembly. If you have a bunch of constants: byte foo = 49; byte bar = 93; etc you can actually get a little bit of assembly language in there, and then by messing up a function pointer or something similar you can get that to execute.
One thing that struck me in all these is how hard all these attacks would be in Java.
First, buffer overflows are right out. Java doesn't allow mem access. Second, back-door assembly is right out. There's no way to execute assembly in Java. The while(a = b) trick is out; Java won't compile that. The stat attack is mostly out. Correctly-written Java objects used named accessor methods so you can't mistake-on-purpose flub which member you're accessing. So what does that leave? There are still some things that could be done in Java but I think it's a lot harder and I don't want to give away any tricks on it!
Maybe I need to start a Java competition like this to see what (if anything) we can shake out. Interesting that no one has an "obfuscated Java" competition either; it just wouldn't be fun or interesting.
------------
Contact management, schedule management
I think, with creative use of bad programming, you could corrupt either the salt or the calculation of the hash function in such a way as to guarantee that for a target OS the hash-table performance would degrade into worst-case. So if you took your borked hash table, and used it to implement an associative array, the fairly trivial read in stdin, increment fields in associative array, sort array in order code could be made to perform at average time complexity in non-targetted OSes and worst-case time complexity in your target OS. Assuming you pick an O(n log n) sort algorithm, if you manage to "accidentally" make each of those n's actually polynomial complexity (heck, n^2 even) the computer should essentially blow up on non-trivial data sets. Its late in the evening and I haven't thought through this very much, but one way would be to use utsname's sysname thing as part of your "random data" to make the salt. That sounds a little obvious though. Maybe there's some obscure function somewhere for getting dates or times or something that I can exploit format of the returned data to reveal the difference between OSes, as that would be a lot harder to detect ("oh, seeding a hash function with a date and some magic numbers, nothing wrong with that").
Anybody got any ideas or corrections to share? Its been a while since I've taken data structures, and I've got essentially no ideas for obscure functions revealing system differences to exploit (C isn't my bag).
Help poke pirates in the eyepatch, arr.
Your code is dangerous, but it has to be exploited by a knowledgable user. I think what they're looking for in the Underhanded C Contest is code that exploits itself. But for the purpose of being pendantic, i'll bite... =)
Lindsey
@>-->-----
Hasn't this kind of challenge already been done.
I think the winner was a piece of code that used an overflow while parsing image data so that code stored in the image file was executed.
The prize should go to the government guys and their improved / optimized / more secure version of the encryption algorithms which compete for the status of 'state standard'.
[think DES, think S-boxes]
: undefined reference to `LaunchMissles'
collect2: ld returned 1 exit status
Emacs is good operating system, but it has one flaw: Its text editor could be better.
There is good way to measure the real difference of different distributions!
Emacs is good operating system, but it has one flaw: Its text editor could be better.
uint32 foo = 0;
uint8 *bar =
*bar = 3;
while(foo--) {
do_something();
}
You've got the point? With the right endiness, foo will not become '3', but more like 3*124 = ca. 50 Mio.
get the fuck out
never admit you don't know something
Its basics of benchmarking. The goal of producing benchark that performs given task and results show one system inferiour to other is REALLY easy. Too bad I don't have one of the old mac mini:s to show my athlon64 the superiority of RISC architecture. We all know very well that RISC is 1000 times faster than CISC dinosaur.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
Sounds like your typical WndProc() function :o)
Slashdot entertains. Windows pays the mortgage.
Underhanded ... doesn't sound that much different to Understaffed ... the resulting code probably has about the same number of defects ...
What is real programming?
First of all it is not programming in C,nor Java, nor LISP, nor Prolog, nor Python.....
LISP, Prolog, Python, Perl, CafeOBJ, Maude are based on concepts more or far more advanced then those on which C is based.
And no one cand deny that a 1000+ lines LISP source code is harder to understand than a C code of the same length. (of course it depends on the purpose of the program written).
And LISP has no pointers.
In conclusion, try not to judge one programming language only through the prism of one characteristic (e.g.: having or not pointers)
since I don't plan to spend any time on this one, I thought I'd start a thread on ways to attack OS specific issues for people that do want to try (the hard version - non hardware dependent - architecture is easy - endian-ness, pipeline, unaligned memory copies, etc).
since you can't rely on architecture, and can't attack stuff like endian-ness, you need to hit the nuances of the OS. One way I can think of is exploit size differences of stuff like wchar_t, since it's 4 bytes on most newer flavors of BSD (e.g. MacOSX) and 2 bytes on Linux, Windows, AIX, and perhaps others. Forcing a call to get sizeof(size_t) repeatedly if the size is not 2 would be another.
For Windows to look good, you might be able to do something with line endings, but that may not be enough (since Linux or whatever could add them in their data, too) - try threads. Most OS's use pthreads, but Windows does its own - use that to your advantage. Also use the built-in thread pool functionality of Windows but always destroy and recreate the threads in pthreads. I'd say to use expensive calls like fork() on UNIX boxes, but if I were a judge, I'd call you on that. You could also do mean tricks like forcing locks on critical sections when geared towards the OS you don't like (or force a long delay like 500ms if another thread has the "token" to chose a line then make the code never hit that condition for the preferred thread type).
how would you do it (if you don't want to bother trying, that is)?
Furthermore, if the buffer is undersized the function will likely appear to act correctly, but may cause an apparently unrelated failure somewhere else in the code, which makes pointer related errors much harder to track down.
We can use a safe C-like language such as Cyclone. But reading the huge number of rules that Cyclone enforces to make pointers safe only reinforces that it is hard it is to be 100% sure that a non-trivial use of a pointer is safe in a C program.
Further more I understand that ~50% of security holes are caused by misuse of pointers. Programmers *will* make mistakes, but programs written in "safe" languages save you from over half of them.
Having said that I write a lot of code in C. However most of it is fairly trivial stuff and not security critical.
Any Tom, Dick or Harry can write subtly malicious steganographic code, or obfuscated ones. Real programmers leave no traces in their source codes: Bow to the leetest hack of them all.
My original objections, that we cannot verify that the psuedo-array "s" is as large as we think it is, or even that "s" is allocated still apply if we do not use fgets or a null-terminated strings e.g. they still apply to the function:
The only additional failure of null-terminated strings is that they are mildly confusing because you need a n+1 sized buffer to store n characters. However a null-terminated string would be perfectly safe if it were stored in a Java-style array.
In C there is no way for a function to verify that it has been called correctly. Perhaps more seriously, if you call a function in a pointer language you cannot treat it as a blackbox. To be sure that it doesn't corrupt your memory you have to closely check their source code to verify that it uses pointers correctly.
The ideal case would be e.g. a functional language where you could call Osamas_pretty_icon_function() and be sure that the worst that could possibly happen is that Osama wrote the function to return a ugly icon instead.
Since we assume that "Data" is 100 bytes it makes little difference whether we add an extra parameter to the function. If the calling function incorrectly believes that it has enough space for 100 bytes, then it makes little difference whether is (incorrectly) states explicitly that it has enough room for 100 bytes or just implicitly assumes it has enough room. Either way readdata cannot check sizeof(s)>100.
Yes you could disallow use of pointer arithmetic, and use bounded arrays, although C doesn't have primitives for this.
Note that C++ will have automatically freed the temporary object "a" by the third line, and so you will be messing with unallocated memory. This code will work 99% of the time, and thus will only fail at the most embarrassing possible moment.You could still have code like this:
Now you could get around this somehow, e.g. by garbage collection, but you will either be left with something like a Java reference or something obscure such as one of several different types of pointer supported by the Cyclone l language.
So basically, yes you could limit pointers to the extent that they cannot cause strange non-local and non-deterministic problems. But then they wouldn't really be pointers anymore.