[SGVLUG] Reverse Engineering / Analyzing the SELinux Kernel Source Code?

[Jeremy Leader]

Dustin Laurence wrote:
> I also like his point that it's likely that you could just get away with
> doing a preprocessing transform of an untrusted compiler's source;
> randomly renaming symbols would foil most obvious backdoors while
> preserving the semantics.

I thought Thompson addressed this (based on my vague memory of reading
the paper when it was first published).  The backdoor just has to do
a pattern-match on the intermediate representation, much like the
unification algorithm Prolog uses.  Simple changes like renaming
variables wouldn't help.  Re-ordering declarations (as well as renaming
them) might help against a dumb backdoor which identified variables by
the order in which it saw them.

A really well-written backdoor would be immune even against semi-semantic
changes like replacing for loops with while loops.  However, I suspect
that as you increase the sophistication of your protective transformation,
the level of effort (programmer time and cpu time) for you to perform
the transformation grows more slowly than the level of effort for the
backdoor to detect its target in the transformed source.

-- 
Jeremy Leader
jleader at alumni.caltech.edu
leaderj at yahoo-inc.com (work)