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."
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
...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.
main() {
printf("hello, world\n");
}
An oldie but goodie . . .
while (1){
status = GetRadarInfo();
if (status = 1)
LaunchMissiles();
}
Heh, I've been ranting for years how I love C and C++ and how Java and pretty much all other higher level languages suck. I think they are ment just for crybabies who can't handle pointers and get confused while tying their shoelaces.
I actually just thought that I'll whip something up for the contest. You know, first I'll just make the basic program and try to figure out how to sneak something in. It took me 10 minutes to realize that I have no fucking clue what I'm doing.
"How do I read from stdin?"
"How do I allocate without too much overhead for it?"
"Wait, I really shouldn't be doing this in the main function. Perhaps I'll make a separate function. Now, hmm.. How do I define a function which takes a reference to an array of char pointers, and what else do I need to know to reallocate the array"
"Oh right. It also needs to be separated by spaces too, not just newlines"
"I wish there was a nice library function 'char *readfile(stream)' in ANSI C"
"Shit. Real programming is hard!"
I hereby turn in my coding gloves, and don the pink fluffy Java gloves I have actually worn for some time against my will.
Bot Assisted Blogging
Er, Java has pointers. They are called references and you HAVE to use them every time you pass an object around - that includes any arrays, including arrays of primitives. It's just that in Java you don't have a choice on how to pass parameters to methods.
Sometimes the truth is arrived at by adding all the little lies together and deducting them from all that is known.
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
@>-->-----
im not very good at programming. but apart from using fgets which gcc says is dangerous...what is the nastiness in question here?
printf(stuf) is dangerous because "stuf" is being used as the format specifier to printf.
Now, normally you use printf like this: printf("%s", stuf), which says to print the string contained in stuf to stdout. But with the printf(stuf) line, you can carefuly craft what is in stuf to make it execute arbitrary code. The key to doing this lies in the %n specifier.
If you were to do printf("Ha!%n",&some_int), then not only would the word "Ha!" be printed to the screen, but the contents of some_int would get set to 3, since that's how many characters were printed and that's what %n is telling it to do.
Now, say I pass in "%X" as stuf. My output will be a number. What number is that? Why, it's the return address of printf, because %X is really telling it to print the contents of the next address on the stack, and that address happens to be a return address (since we didn't pass in real arguments to printf). If I therefore carefully craft my string, I can not only overwrite that return addres using %n, but I can overwrite it with a pointer to a location which will be executed when printf returns by varying the length of my string. And I can easily vary the length of my string by doing some things like %.1234x in there, which will happily stick 1234 characters in my string easily and add 1234 to n.
Once I know the return address, I can work out where my string buffer is actually being stored, and then I can include my exploit code in that string itself, and execute it right from there.
Short version is that passing format specifier strings to printf as anything other than literals is dangerous unless you know exactly what the format specifier string really is.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.