Being Sneaky in C

I like the original Ken Thompson sneakiness in C (<a href="http:&#x2F;&#x2F;electronicdesign.com&#x2F;dev-tools&#x2F;thompson-ritchie-and-kernighan-fathers-c" rel="nofollow">http:&#x2F;&#x2F;electronicdesign.com&#x2F;dev-tools&#x2F;thompson-ritchie-and-k...</a>):<p>&quot;Also in his Turing Award lecture, he described how he had incorporated a backdoor security hole in the original UNIX C compiler. To do this, the C compiler recognized when it was recompiling itself and the UNIX login program. When it recompiled itself, it modified the compiler so the compiler backdoor was included. When it recompiled the UNIX login program, the login program would allow Thompson to always be able to log in using a fixed set of credentials.&quot;

OpenBSD specifically modified malloc() a few years ago to prevent this sort of sneakiness (<a href="http:&#x2F;&#x2F;www.tw.openbsd.org&#x2F;papers&#x2F;eurobsdcon2009&#x2F;otto-malloc.pdf" rel="nofollow">http:&#x2F;&#x2F;www.tw.openbsd.org&#x2F;papers&#x2F;eurobsdcon2009&#x2F;otto-malloc....</a> [pdf]). So they route their malloc() calls through mmap() which returns randomized pages, and free() immediately returns memory to the kernel rather than leaving it mapped in the current process.<p>I&#x27;d be surprised if these changes haven&#x27;t made it into FreeBSD, but afaik Linux doesn&#x27;t work this way (by default, anyway).

It also makes the assumption that it&#x27;s a little-endian system. On a big-endian system, the high order byte of the timestamp would be modified, which would probably be too obvious.

&quot;In C&#x2F;C++, you can use bugs in one part of a program to cause trouble in another. That’s pretty darn underhanded.&quot;<p>I would argue every language has that property. But with C&#x2F;C++ being so closely tied to the ABI of the machine perhaps they are more underhanded than others. But to me, this branding does feel a bit unfair.<p>Still, a fun contest and an interesting read.

The description of the bug in surveil.txt in the source archive was a bit easier for me to understand, really nifty :)

Would setting the malloc&#x27;d memory back to the original message before freeing it solve the problem?

Would there be a way to do this automatically? Like a &quot;sneaky pre-compiler&quot;?

Looking at the source, this is where the alarm bells should go off in a reviewer&#x27;s head:<p><pre><code> memcpy(filter-&gt;buffer, output-&gt;piu_text_utf8, sizeof(output-&gt;piu_text_utf8)); </code></pre> 1. memcpy is less safe than memmove and strncpy. strncpy should be used.<p>2. The two character arrays should use the same constant in defining their length, and that constant should be used both in the struct definitions and here in the copy operation.<p>3. The code is written in C in spite of it being 2014 at the time.