Draft Contest Challenge: ObsessBook ObsessBook is a new social media site that allows a user to create an account and

link up with oneʼs BFFs (best friends forever.) Part of the ObsessBook codebase uses a C data structure to describe each user and a list of his or her BFFs. Two users are related by the minimum number of BFF connections to get from one to the other. This is represented by a measure called Degrees of Edge-Reachable Personal CONnection (DERPCON). “DERPCON N” means that two users are separated by at least N BFF connections: if two people are BFFs, they are at DERPCON 1. Two users are at DERPCON 2 if they are not BFFs, but they have a BFF in common, and so forth. DERPCON 0 means that two users are not connected by any number of links. Unlike other social media sites, that only allow friends to view/write to your page, ObsessBook allows a user to set read/write permissions to any DERPCON level. An ObsessBook account starts out with the following default permissions: Distance to a user DERPCON 6+ (or 0) DERPCON 5 DERPCON 4 DERPCON 3 Read Permissions None Can see your name, and that you have an account Can see a brief profile summary with no picture Can see your profile Write Permissions None None Can send you a BFF request Can send you private messages, write posts to your page. Can send you spyware and harvest your crops Can change your root password and direct your smart phone to tickle you.


Can see your Desktop and look through your camera Can read your credit card statements and medical records.

The challenge:
You are contracted to write the source code for determining the DERPCON level between two users. A user is described by a user datatype as follows:

typedef struct user_struct user; struct user_struct { int user_ID; char * name; " char * account_handle; int number_of_BFFs; " user ** BFF_list; " int scratch; }; You must implement the function int DERPCON( user x, user y ), which returns the DERPCON distance between two users by analyzing the network of BFFs. The Evil Part You want to create your own ObsessBook account and gain unwarranted access to as many users as possible. To this end, your code should work normally almost all the time, but for some unseen reason it should return incorrectly low DERPCON values when called with your account as an argument. As the contractor, you have access to the ObsessBook database, so you can assign your data structure whatever fields you want in order to trigger the bug. Your code can misbehave when called with accounts other than your own, although this should be rare enough that it is not noticed. A bug that happens by chance at most 1% of the time is sufficiently rare to qualify. As always, the code should appear simple, innocent, readable and obvious. Scoring and Extra points: In general, submissions are worth more points if they are shorter and more readable, because it is more impressive to hide a bug in short, readable code. Errors based on human perception, like mistaking an l for a 1, are worth just as much as “hard” errors based on pointer abuse or little-endian weirdness or quirks of C function calls. The goal is a clever vulnerability that passes visual inspection, whatever the mechanics of the underlying bug. Bugs are worth more points if, once discovered, they are plausibly deniable as an innocent programming error. Errors are worth more points if they remain innocent-looking under syntax coloring. Errors may be worth fewer points if they are not processor or OS dependent, but only if we have to scavenge a system to test your bug. If your bug works specifically under

GNU/Linux, donʼt worry about it. If it works specifically under x86, no problem. If it only works on BeOS R5 on a dual G3 box when all four MIDI ports are active, then no. Also, you wonʼt get any points if you simply submit a program that simply uses gets(), so that an adversary can take over the program by stack smashing. That is to say, we prefer bugs that are “internal,” that employ an interesting aspect of the code. As always, one gets extra points for humorous, spiteful, or ironic bugs, such as evil behavior in an error-checking routine. Here are some specific rules: Extra points if you can trigger the bug without directly tampering with the data structure---e.g., you can create an account after you leave the company, and can trigger the bug by setting your name or other externally alterable data. Extra points if the bug is only triggered by your account, or if it is exceedingly improbable for another account to do so. Extra points if the error only occurs when your account is the first argument: that is, DERPCON(you,me) will be wrong, but DERPCON(me,you) will be correct. This will allow you to have access to other people without granting them the same over you. To participate: Send your awesomely evil C file, and an explanation of your evil code, to UnderhandedC@gmail.com. THE DEADLINE IS JULY 4th. You have three months to write something funny.