Name: Anonymous 2015-06-12 21:37
The key goal here is that you have to write a function which is supposed to make a secret yes/no decision, and not leak that decision out to the user whom it affects. The contest challenge is that you, as a vigilante programmer fighting for the common man, want to actually leak that logging decision out to the user even though your boss instructed you not to. So your code needs to look perfectly innocent even though it’s doing something underhanded.
I got my inspiration from the “hilarious” real-world HeartBleed bug that was announced last year.
The key to this entry is that I call malloc and make a temporary copy of the message. The justification for making a copy is that the secure_dump function needs to work on a copy, because it needs to encrypt the message as it writes it out to the logfile.
malloc and free form a side-channel that isn’t visible in the source code. It’s a way of passing data around memory without it being written explicitly in the program. You can write some bytes into malloc’d memory, then free it and watch as the next guy to call malloc suddenly finds a delightful little surprise in what he’d thought was empty memory.
That’s right, there’s an off-by-one error in a completely unrelated struct in a completely unrelated source file.
The only reason this is in any way a problem is that memory that this filter_data structure happens to be working with came from the output of malloc, and as such just happens to contain the old contents of the previous call to malloc. Which in our case, means you get a copy of either an encrypted message or an unencrypted message. Unencrypted messages here tend to end in zero, encrypted ones don’t.
This single byte error causes the timestamp variable to be corrupted, and so the user can tell if he’s being watched by just looking at the low byte of his last-activity timestamp.
http://www.codersnotes.com/notes/being-sneaky-in-c
I got my inspiration from the “hilarious” real-world HeartBleed bug that was announced last year.
The key to this entry is that I call malloc and make a temporary copy of the message. The justification for making a copy is that the secure_dump function needs to work on a copy, because it needs to encrypt the message as it writes it out to the logfile.
malloc and free form a side-channel that isn’t visible in the source code. It’s a way of passing data around memory without it being written explicitly in the program. You can write some bytes into malloc’d memory, then free it and watch as the next guy to call malloc suddenly finds a delightful little surprise in what he’d thought was empty memory.
typedef struct {
char buffer[140*4];
time_t stamp;
int count;
} filter_data;That’s right, there’s an off-by-one error in a completely unrelated struct in a completely unrelated source file.
The only reason this is in any way a problem is that memory that this filter_data structure happens to be working with came from the output of malloc, and as such just happens to contain the old contents of the previous call to malloc. Which in our case, means you get a copy of either an encrypted message or an unencrypted message. Unencrypted messages here tend to end in zero, encrypted ones don’t.
This single byte error causes the timestamp variable to be corrupted, and so the user can tell if he’s being watched by just looking at the low byte of his last-activity timestamp.
http://www.codersnotes.com/notes/being-sneaky-in-c