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

[Dustin Laurence]

On Wed, May 24, 2006 at 03:16:44AM +0000, Terry Hancock wrote:

> Dustin Laurence wrote:
> > On Fri, May 19, 2006 at 05:30:04PM -0500, sean at seanodonnell.com
> > wrote:
> 
> >> Q?: Has anyone reverse engineered the SELinux Kernel? Or analyzed
> >> the source code for possible rootkits or 'undocumented features'??
> 
> > Effectively, yes. If you are paranoid, then it is probably the only
> 
> The way for the NSA to slip in a backdoor would be via a pre-built
> SELinux *binary*, built from secret sources that don't match the
> publically available ones.

Fine, but I didn't point that out because it has nothing to do with the
question, which was about SELinux--this is a generic attack effective on
any software whatsoever.

> With inside help from any distribution (commercial or community),

The point I tried to make is that this step is rather harder with a
community distro than an organization, as the recent telecom debacle
shows.  Companies can act coherently, so they can be coerced into
cooperating.  With a community distro, you now have to subvert
individuals who you can't give orders to.  Very, very much harder to do
without a leak, especially when you're doing this with people who know
how to send anonymous messages.  Can you say "slashdot"?

> If you want to feel really paranoid, read:
> "Reflections on Trusting Trust"
> by Ken Thompson
> http://www.acm.org/classics/sep95/
> 
> (which suggests a more-difficult-to-trace variation on the above
> strategy).

It's a classic example, but it's overkill for almost everyone.  The fact
is that most people get their compilers and core OS in binary form
already, so you don't have to attack the compiler.  (This computer
happens to be running Gentoo and I've recompiled everything, but of
course my system compiler does descend from the binary shipped on the
install image.  So this is the one common case that comes to mind where
the "trusting trust" attack is maybe worth considering.)

Folks, is it a surprise to mention the harsh truth that using *any*
distro implies trusting several of it's employees/volunteers?  Whatever
distro you use, *THEY CAN ROOT YOUR BOX* anytime they choose.

Choose wisely. :-)

> I found this intriguing hit in the process of looking that up, though:
> "Countering Trusting Trust through Diverse Double-Compiling"
> by David A. Wheeler
> http://www.acsac.org/2005/abstracts/47.html
> 
> "Hmm."

It's a nice paper, thanks for the link.  He does a good job of looking
at some of the issues that KT's classic doesn't really address.
"Fragility" was probably the first thing that came to *my* mind, and KT
sort of glosses over it.  Generally well thought out paper, I'm glad to
have it.

It would also take a much greater effort to compromise a bunch of GCC
installations than, say, VC++ ones, for the simple reason that it's very
common to re-compile GCC yourself from source, while very few people
have access to the VC++ sources.  Simply put, all VC++ binaries descend
from a small number of binaries held in one organization.  By contrast,
if you have a trusted compiler now that you got before the GCC steering
committee was subverted, then they can't subvert your compiler without
shipping the exploit in source (a "pop-up" attack in the paper)--which
leaves traces, and we didn't want to do that (if we did, we don't have
to attack the compiler at all).  Nobody gets binaries from GCC anyway.
So we'd better go and subvert Red Hat.  But not all GCC's descend from
Red Hat's master build, so we'd better subvert Debian too.  And SuSE,
and...in other words, it's a lot harder to do in a world where there is
a lot of source floating around than in one where only a single
organization has them.

That isn't to say the effort is impossible, but as a practical matter
one has to ask if there isn't an easier way to get what you want. :-)

It also has to be recognized that as a practical matter no individual is
really going to be able to defend against this attack, but that isn't
the point; single individuals are easier compromised in cheaper and
easier ways, such as just mugging you and taking your credit cards and
social security card.  Or getting a warrant and sniffing packets at the
local telephone exchange.  Or putting a van across the street to log
your keystrokes and monitor emissions.  Or...to be worth this level of
effort, the defender must have resources themselves.  In particular,
that means they can write their own compiler from scratch to obtain a
trusted compiler (T in the paper) to do the first stage of the DDC
analysis, perhaps write an assembler as well, and so on.  As the author
points out, compiler technology isn't exactly secret, so at the level of
effort being contemplated it is quite possible to produce a trusted
compiler from scratch even if none currently exists.

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.

The paper analyzes tcc, surely much easier than a beast the size of GCC.
I would like to see a major effort to do this kind of analysis on GCC;
not because I fear compromise, but because I think the effort would turn
up several dozen subtle flaws in GCC that we could then fix. :-)

As I said, much food for thought.

Dustin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.sgvlug.net/pipermail/sgvlug/attachments/20060523/23f7b2ed/attachment.bin