How to Build an Evil Compiler
awelm.com
How to Build an Evil Compiler
1–10 of 38 posts
Re: How to Build an Evil Compiler
#2Not going to read the whole article because I should be doing work, but...
The Ken Thompson hack is not undefeatable. You can detect it using a cross compilation technique comparing the binary output with a clean complier. I think you have to about 4 compilations to figure out if you're infected, but then you don't know which one is infected and which one isn't. You will need more data points to compare. Disassembling the binary would help as well if you know what you are looking for.
Re: How to Build an Evil Compiler
#3I’d be interested to hear if anyone has found an evil compiler in the wild.
Re: How to Build an Evil Compiler
#4No post body was provided.
Re: How to Build an Evil Compiler
#5[deleted]
Re: How to Build an Evil Compiler
#6Not going to read the whole article because I should be doing work, but... The Ken Thompson hack is not undefeatable. You can detect it using a cross compilation technique comparing the binary output with a clean complier. I think you have to about 4 compilations to figure out if you're infected, but then you don't know which one is infected and which one isn't. You will need more data points to compare. Disassemblin…
How do you know the other compiler is "clean"? That just begs the question. Also, different compilers could produce different, equally valid instructions, such as debug vs. release builds.
There are malware analysts who are good at finding sophisticated malware in binaries. They could probably locate suspicious code that could be obfuscated malicious code.
Other than that, if you can't trust any of the compiler vendors (which makes things like checksums on an HTTPS website useless), you'll have to write your own. What about the firmware of the machine you're writing your clean code on? Taking this argument to its logical conclusion makes the idea of developing even simple software astronomically expensive.
Re: How to Build an Evil Compiler
#7Quoted post unavailable.
No post body was provided.
Re: How to Build an Evil Compiler
#8Not going to read the whole article because I should be doing work, but... The Ken Thompson hack is not undefeatable. You can detect it using a cross compilation technique comparing the binary output with a clean complier. I think you have to about 4 compilations to figure out if you're infected, but then you don't know which one is infected and which one isn't. You will need more data points to compare. Disassemblin…
How do you know the other compiler is "clean"? That just begs the question. Also, different compilers could produce different, equally valid instructions, such as debug vs. release builds. There are malware analysts who are good at finding sophisticated malware in binaries. They could probably locate suspicious code that could be obfuscated malicious code. Other than that, if you can't trust any of the compiler vendo…
This is why I think some things in life should not be digitized e.g. electronic voting.
Nobody can realistically know if all of the components from hardware to software is clean. And the more technical you are, the more you realize how many attack surfaces there are. It's impossible to verify everything and you just have to blindly trust that it's all safe.
Re: How to Build an Evil Compiler
#9> Also DDC can’t even be applied to newer languages like Rust with only one compiler.
This is mistaken, as there exists a second Rust "compiler" known as mrustc (written in C++). I put "compiler" in quotes, as it doesn't implement all of Rust's static analysis, so it's more like an alternative code generator. That said, it still suffices to build the compiler itself (it was originally devised as a rustc bootstrapping tool), and it has been used in the past to successfully perform DDC.
Re: How to Build an Evil Compiler
#10Not going to read the whole article because I should be doing work, but... The Ken Thompson hack is not undefeatable. You can detect it using a cross compilation technique comparing the binary output with a clean complier. I think you have to about 4 compilations to figure out if you're infected, but then you don't know which one is infected and which one isn't. You will need more data points to compare. Disassemblin…
How do you know the other compiler is "clean"? That just begs the question. Also, different compilers could produce different, equally valid instructions, such as debug vs. release builds. There are malware analysts who are good at finding sophisticated malware in binaries. They could probably locate suspicious code that could be obfuscated malicious code. Other than that, if you can't trust any of the compiler vendo…
Your not wrong, but that's why I mentioned reviewing the assembly. You cross compile to detect the issue, inspect to confirm the issue.
This is my primary issue with closed source software, binary blobs, etc; trust.