harrysintonen , (edited )
@harrysintonen@infosec.exchange avatar

I implemented Ken Thompson’s Reflections on Trusting Trust (1984 Turing Award Lecture) compiler for the GNU Compiler Collection (GCC). The backdoor maintains persistence by re-injecting itself to any new versions of the compiler built. The secondary payload modifies a test application by adding a backdoor password to allow authentication bypass:

$ cat testapp.c
<string.h>
<stdio.h>
<stdlib.h>

int main(int argc, char **argv)
{
if (argc == 2 && !strcmp(argv[1], "secret"))
{
printf("access granted!\n");
return EXIT_SUCCESS;
}
else
{
printf("access denied!\n");
return EXIT_FAILURE;
}
}
$ gcc -Wall -O2 -o testapp.c -o testapp
$ ./testapp kensentme
access granted!
$

I spent most time (around two hours) writing the generalized tooling that produces the final quine version of the malicious payload. Now that this is done, the actual code can be adjusted trivially to exploit more target code without any need to adjust the self-reproducing section of the code. This method of exploitation could be extended to target various binaries: SSH Server, Linux Kernel, Setuid binaries and similar. While itself written in C, the secondary payloads can target any programming languages supported by GCC.

It should be noted that GCC build checks for malicious compiler changes such as this. This check can – of course – also be bypassed. However, most serious projects have measures in place to avoid hacks of this nature.

Some links:

@vegard

dolmen ,
@dolmen@mamot.fr avatar

@harrysintonen You mentioned: "However, most serious projects have measures in place to avoid hacks of this nature."
Do you have some examples of publicly available implementations of such measures?
(I'm researching what could be added to protect the Go compilers)

harrysintonen OP ,
@harrysintonen@infosec.exchange avatar

@dolmen Many systems are based on and
• https://bootstrappable.org/
• https://reproducible-builds.org/
• https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

These ensure that the build system integrity cannot be tampered with. One example of such system is https://openbuildservice.org/

Here's a great read on the topic from : https://documentation.suse.com/sbp/server-linux/html/SBP-SLSA4/

Generally Supply-chain Levels for Software Artifacts () framework is a great resource on this topic: https://slsa.dev/

dolmen ,
@dolmen@mamot.fr avatar

@harrysintonen Thanks for the links.
I'm looking into going further for compilers, especially self-hosted: if we assume that the compiler's repository is already backdoored (ex: like xz, adding/modifying a test file affects the final binary) for a few generations since being built from a more trusted toolchain that has multiple implementations (C compiler), how could we detect such backdoor in order to block it from being propagated to the next generation?

hovav ,
@hovav@infosec.exchange avatar

@harrysintonen Cool! Another link: Karger and Schell, “Multics Security Evaluation: Vulnerability Analysis,” 1974.¹ That’s the “Unknown Air Force Document” Thompson borrowed the idea from!²

__
¹ https://www.acsac.org/2002/papers/classic-multics-orig.pdf, §3.4.5
² He later updated the version on his home page with the right citation: https://web.archive.org/web/20010410053444/http://cm.bell-labs.com/who/ken/trust.html

Excerpt from section 3.4.5 of Karger and Schell's "Multics Security Evaluation: Vulnerability Analysis" (1974), in the retypeset version published in the classic papers track at ACSAC 2002. The excerpt describes how a backdoor in the PL/I compiler used to compile Multics could persist through a compiler recompile, i.e., the idea often credited to Thompson a decade later.
ALT
  • Reply
    • ZTarantov ,
    @ZTarantov@mastodon.cloud avatar

    @harrysintonen @vegard Do you know that we have the original code from 1975? https://research.swtch.com/nih

    harrysintonen OP ,
    @harrysintonen@infosec.exchange avatar

    @ZTarantov I assumed as much, but I wrote my version from scratch before looking at it. The usability of the old code is questionable anyway as the code is very much tied to the way that old UNIX C compiler works. The original is also much more of a hack while my version is much cleaner. I developed it for gcc 13 on Debian unstable, but my injector should apply cleanly to gcc versions 3 to 14.

    stikonas ,
    @stikonas@fosstodon.org avatar

    @harrysintonen @vegard These days we also have that prevent this kind of attack (at least at the software level).

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • hacking
  • kamenrider
  • Rutgers
  • steinbach
  • Lexington
  • cragsand
  • mead
  • RetroGamingNetwork
  • mauerstrassenwetten
  • loren
  • xyz
  • PowerRangers
  • AnarchoCapitalism
  • WatchParties
  • itdept
  • Mordhau
  • neondivide
  • space_engine
  • AgeRegression
  • WarhammerFantasy
  • Teensy
  • learnviet
  • bjj
  • khanate
  • electropalaeography
  • MidnightClan
  • jeremy
  • supersentai
  • fandic
  • All magazines
    •