From a post I just made elsewhere, about Recall:

Because Recall is "default allow" (it relies on a list of things not to record) ... it's going to vacuum up huge volumes and heretofore unknown types of data, most of which are ephemeral today. The "we can't avoid saving passwords if they're not masked" warning Microsoft included is only the tip of that iceberg. There's an ocean of data that the security ecosystem assumes is "out of reach" because it's either never stored, or it's encrypted in transit. All of that goes out the window if the endpoint is just going to ... turn around and write it to disk. (And local encryption at rest won't help much here if the data is queryable in the user's own authentication context!)

Put another way: no one has been writing their apps or libraries assuming that this data might be captured somewhere. Some suuuuper deep assumptions about that will only come to light once they've been painfully exploited - and may take a ton of time to remediate.

Most {organizational, ecosystem, societal} threat models don't include "run infostealers on steroids on every endpoint that anyone in the user's authentication context can query".

Ransomware of unprecedentedly juicy exfil (enabled by maliciously configuring it to strip out any "do not record" exceptions for a while) will have a field day. PCI / GDPR / etc implications are mind-boggling.

And Recall's users and Microsoft are going to learn all this the hard way.

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: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
- David A. Wheeler: "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers" https://dwheeler.com/trusting-trust/

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