$ cat test.c<br>#[url=https://infosec.exchange/tags/include]include[/url] <stdio.h><br><br>struct nested {<br>  int n;<br>};<br>struct foo {<br>  int member_a;<br>  unsigned long member_b;<br>  char *str;<br>  void *ptr;<br>  struct nested nested;<br>};<br><br>int main(void) {<br>  struct foo f = {<br>    .member_a = 123,<br>    .member_b = 0x4141414141414141,<br>    .str = "foobar",<br>    .ptr = &f,<br>    .nested = {.n = 42}<br>  };<br>  __builtin_dump_struct(&f, printf);<br>}<br>$ clang -o test test.c && ./test<br>struct foo {<br>  int member_a = 123<br>  unsigned long member_b = 4702111234474983745<br>  char * str = "foobar"<br>  void * ptr = 0x7fff1df41b78<br>  struct nested nested = {<br>    int n = 42<br>  }<br>}<br>

Introduce a new builtin, __builtin_dump_struct, that is useful for du… · llvm/llvm-project@0652534

…mping structure contents at runtime in circumstances where debuggers may not be easily available (such as in kernel work). Patch by Paul Semel. llvm-svn: 329762

^GitHub

I implemented Ken Thompson’s Reflections on Trusting Trust (1984 Turing Award Lecture) compiler #backdoor 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
#include <string.h>
#include <stdio.h>
#include <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:
- Ken Thompson's "Reflections on Trusting Trust" paper: cs.cmu.edu/~rdriley/487/papers…
- David A. Wheeler: "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers" dwheeler.com/trusting-trust/

#hacking #exploitdevelopment #kenthompson #infosec #cybersecurity @vegard

Checking 000-default-le-ssl.conf after successful completion of the certbot HTTPS routine:

Certbot entered more lines in the already existing file that was created by scratch when executing
sudo nano /etc/apache2/sites-available/000-default-le-ssl.conf
creating a complete mess.

It created kinda a double entry and also added <VirtualHost *:80>
I started testing and comparing and ended up with the following file:

With <VirtualHost *:80> firefox gives a:
SSL_ERROR_RX_RECORD_TOO_LONG error,
so I used port 443 as in the example and apparently that works.