I ran across this article today: http://www.acsa-admin.org/2005/abstracts/47.html
Apparently this is a paper that was just presented at a computer security conference. I read Ken Thompson's "trusting trust" paper way back in the day and was pretty impressed but completely forgot about it because it's not worth worrying about when there is nothing you can do about it. Now this this paper comes along and claims to detect the attack. But it makes a pretty huge assumption: towards the end of section 5 it says "Instead, during DDC we only only use a trusted compilation process T, code generated by T, and other programs in environements which we trust do not trigger on the compilation of Sa." And the first line of section 6 is "DDC requires a trusted compiler T and trusted environment(s) where there is a high degree of confidence that any triggers against Sa that may be in compiler A will not also be present." I thought it was that kind of trust that we couldn't trust in the first place? Have we really accomplished anything towards countering this attack? It seems this counter to the "trusting trust" attack is all about hoping you have enough diversity not to activate the triggers while never really knowing for sure. Section 8 talks about tcc which I had never heard of. Apparently this is a completely fresh ANSI C compiler implementation which is capable of compiling the Linux kernel. In section 8.1 they use gcc to check for malicious behavior in tcc. Why didn't they do it the other way around?! I don't give a care if tcc is backdoored or not but I know a lot of people would be interested in knowing if gcc is! Instead this is left as "Future potential work". -- Tracy R Reed http://copilotconsulting.com 1-877-MY-COPILOT -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
