2

After reading this question about if it's safer to download and compile the source for an open source project or download and run the installer, I thought of another possible vulnerability: is it conceivable a compiler could be designed to leave a back door (or other malware) inside a file it outputs? In other words could the compiler used to compile the source code be compromised? The only way such a thing could be caught would be to dissasemble a compiled executable and compare the code with the original. This would be very difficult.

Also you would need a preexisting compiler to compile an open source compiler. Is it even theoretically possible to have a system that is all open source software and the computer owner (or a group of trusted people) has reviewed the code for the programs used?

Community
  • 1
Celeritas
  • 10,039
  • 22
  • 77
  • 144

2 Answers2

1

Yes, the compiler, as any other program that executes code on your computer, can be used to add malicious instructions in a program, before or also after compiling it (e.g. ELF header and sections manipulation).

ack__
  • 2,728
  • 14
  • 25
1

You need to look at the chain of trust. Do you trust the source of the code author, have you or someone you trust reviewed the code, do you trust the compiler. It is indeed possible for a compiler to be distributed that inserts backdoors, malicious code, etc.

Ken Thompson's Reflections on Trusting Trust, his Turing Award acceptance speech in 1984, was the first major paper to describe black box backdoor issues, and points out that trust is relative.

It's also possible that your compiler may not act as intended and could reduce the insecurity of the code:

Four researchers in MIT’s Computer Science and Artificial Intelligence Laboratory, in a paper which is to be presented next week at the ACM Symposium on Operating Systems Principles, looked at the problem of optimization-unstable code, which is code that gets removed by a compiler because it includes undefined behavior. Undefined behavior is code which can behave unpredictably, such as dividing by zero, null pointer dereferencing and buffer overflows. Unlike other code, compiler writers are free to deal with undefined behavior however they wish. In some cases, they choose to eliminate it completely, which can lead to vulnerabilities if the code in question contains security checks.

Eric G
  • 9,691
  • 4
  • 31
  • 58