Research

Application security testing, analysis, and metrics

Trust Your Own Code?! Trust Your Own Compiler?!

Trust has long been a favorite target of malicious individuals. Most people would say that proper management of trust is one of the primary cornerstones of information security. Trust is a relative term and all trust relationships should be examined with a very critical eye.

Trust - By gypsyrock on Flickr

Ken Thompson’s seminal paper “Reflections on Trusting Trust”, which won a Turing Award, addresses in detail why we can never be fully sure of the trust relationships in our development environment. The paper asserts that since people tend to only review the security of the source code of their programs, and not the resulting compilation, there is a built in level of trust with regard to the tools that convert human readable source code into executable binary programs. According to the paper, this trust can be abused by creating a compiler that outputs something different than originally intended by the source code. No level of source code security review is going to catch this type of malicious activity. To take it one step further, Ken also discusses a malicious compiler that when used to build a new compiler, will make that one malicious as well. Well recent discoveries have shown that the paper is spot on with regards to a new virus that is currently making the rounds.

A few days ago, a security researcher by the name of Andreas Marx submitted a sample of a new strain of virus to a number of anti-virus vendors. This strain, which has been named Win32.Induc.a, was subsequently researched by both Kaspersky Labs and F-Secure with the details being published shortly after discovery. What makes this virus interesting isn’t a devastating payload — it has none — but instead what it targets. When an infected binary is executed it attempts to locate an installation of the Delphi compiler and, if one is present, subverts that target to create a real-life version of Ken Thompson’s malicious compiler. All future programs compiled by the now infected compiler will result in a binary that also contains the virus. Regardless of the security level of the source code fed into the compiler, the output will be dangerous. Some reports have gone so far as to claim that over 200,000 infected files have already been produced by infected compilers. (Take these numbers with a grain of salt of course).

This realization of the “Trusting Trust” subverted compiler demonstrates the need to secure and test exactly what we are going to execute and not what we write. Given the existence of malware like this, it is clear that what we write may be nowhere near what we actually run.

Update: I was just handed a link to a very interesting paper written by Chris Wysopal detailing the relationship of Thompson’s compiler backdoor to binary analysis. Link HERE. This is a must read.

Veracode Security Solutions

Security Threat Guides
2 Comments »

Many thanks for this interesting post. It is a very impressive mechanism for infecting compiled code even when the source code is free of vulnerabilities.

I wonder why Is it so hard to detect this kind of ‘Trojan Horse’ as stated by Ken Thompson’s seminal paper ?
It is clear that compilers cannot be trusted anymore. However, I don’t think that it is hard to detect that the compiler is malicious.
An easy and simple way would be to take a simple program, say the HelloWorld program and a compiled version, a trusted one. For this, the binary code should be reviewed (this is possible, even manually because the code is simple).
Then we compare the compiled version we get using the compiler (to be tested) with the other ‘trusted one’.
No need to go with complex binary analyses, as suggested by Chris’s paper.

Kind regards,
Tejeddine,

Comment by Tejeddine Mouelhi — September 2, 2009 @ 6:54 am

[...] From Zero in a Bit (Tyler Shields) [...]

Pingback by When Trusting Your Own Code is a Bad Idea | Threatpost — March 24, 2013 @ 9:11 pm

RSS feed for comments on this post. TrackBack URI

Leave a comment


Mobile Security

Sql Injection

cyber security

Categories

Archive

Powered by WordPress