Being Sneaky in C

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.

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

well done dude

the “hilarious” real-world HeartBleed bug

Really fucking funny. Epic.

how come /g/entine and all da hackerz@daNSA are makin der way here?

TIL all of the buffer overflows in C code were actually put there on purpose by hackers and vigilante programmers.

>>1
Exploiting information leakage through heap re-use is totally non-portable. Even a minor change to the malloc implementation could break your exploit code.

If your "boss" has a clue they will require you to mlock / VirtualLock sensitive data and memset / SecureZeroMemory when you are finished with it.

>>6
You got a better way to solve the challenge?

>>7
I don't need to do your shitty challenge, I have a master's degree in cum-putter's sky-fence, cunt

>>7
Move the message buffer to the end of the structure, and overrun it only in cases where the user's data is logged. A simple off by one in the logging branch of the code would be sufficient.

This is really insidious because the data you're leaking isn't inside the struct at all. It's also possible to do this is a reasonably portable way by observing commonalities in the struct layout rules for different platforms. If you do it right, you end up with a hole at the end that the ABI prohibits others from using, but which you can still use to stash 1-3 bytes of data in.

Move the project to Seeples, use the Turing completeness of the template system to make a hidden state machine that can effect compilation in such a way to silently introduce a backdoor.

_{(stopping the dubsfaggot from dubsbumping)}