User: Password:
|
|
Subscribe / Log in / New account

Countering the trusting trust attack

Countering the trusting trust attack

Posted Feb 3, 2010 23:24 UTC (Wed) by dwheeler (guest, #1216)
In reply to: Countering the trusting trust attack by paulj
Parent article: Security in the 20-teens

> The work is nice, no doubt, but it still requires 1 absolutely trusted compiler, which would have to be written (or verified/assumed)...

It does not have to be absolutely trusted, in the sense of being perfect on all possible inputs. It can be subverted, and/or have bugs, as long as it will compile the compiler-under-test without triggering a subversion or bug.

> Do you think the "Fully" in the title of your thesis is perhaps unfortunate though? Your work seems to re-enforce Thompson's result rather than fully counter it, surely?

No, it's not unfortunate. It's intentional.

Thompson's "trusting trust" attack is dead. Thompson correctly points out a problem with compilers and other lower-level components, but his attack presumes that you can't easily use some other system that acts as a *check* on the first. It's not just that you can recompile something with a different compiler; people noted that in the 1980s.

A key is that DDC lets you *accumulate* evidence. If you want, you can use DDC 10 times, with 10 different trusted compilers; an attacker would have to subvert ALL TEN trusted compilers *AND* the original compiler-under-test executable to avoid detection. Fat chance.


(Log in to post comments)

Countering the trusting trust attack

Posted Feb 3, 2010 23:40 UTC (Wed) by paulj (subscriber, #341) [Link]

Thanks for your reply. Again, I stress that I appreciate the practical benefits
of your approach.

I saw the caveat in the thesis about the trusted compiler-compiler only
needing to be trusted to compile the 1st full compiler. However, I am at a
loss to see how this trusted compiler (i.e. you inspected all possible relevant
source, or you wrote it) is different from Thompson's trusted compiler ("write
it yourself", see quote above).

Your approach still rests in complete trust in one compiler, according to your
own proofs.

See my other comment about how viruses have advanced from Thompson's
original attack, meaning that a subverted original compiler-compiler could
surely infect all other binaries ever touched by that code through, say, ELF
infections and hooking library calls.

Anyway, I'll leave it there.

Countering the trusting trust attack

Posted Feb 4, 2010 23:11 UTC (Thu) by bronson (subscriber, #4806) [Link]

> Your approach still rests in complete trust in one compiler

No, it doesn't. David described this in an ancestor post. It just rests on the assumption that a single group of attackers can't subvert every single one of your compilers.

Countering the trusting trust attack

Posted Feb 4, 2010 23:54 UTC (Thu) by nix (subscriber, #2304) [Link]

David also described in a recent post how you can ensure that your
compiler groups weren't maliciously cooperating: make sure your compilers
are very different ages. This will only get *better* as the years roll
past, especially once Moore's Law grinds to a halt: if one compiler is a
hundred years older than the other, unless there's an immortal on the
development team there's no *way* they share members. (These days of
course this gap is impractical because computers are changing too fast.)

Countering the trusting trust attack

Posted Feb 5, 2010 0:30 UTC (Fri) by Baylink (guest, #755) [Link]

In particular, this works very well if your check-compiler was shipped *when your target compiler/platform did not even exist yet*.

It would be hard to have hot-wired an early-90s IRIX compiler to break GCC4/Linux.

Countering the trusting trust attack

Posted Feb 5, 2010 19:33 UTC (Fri) by paulj (subscriber, #341) [Link]

How does it get better exactly? Old software doesn't come sandwiched,
ossified between rock strata that can further attest to its obvious age.

You're still going to have to determine whether or not the bag of bits you have
before you really is the same as that old compiler you want to put your faith in.
You'll have to trust your md5sum binary (oops) and you'll have to trust MD5.
Oops. And you're still trusting the original compiler author.

The "they old author can't have thought of future compilers" argument seems
weak. Viruses are much more sophisticated these days - there's no need the
attack has to be limited to specific implementations of software.

I know David's paper frames the problem so that the attack in fact does have
that limitation, but that seems an unjustified restriction of Thompson's attack.

Countering the trusting trust attack

Posted Feb 5, 2010 19:44 UTC (Fri) by Baylink (guest, #755) [Link]

> How does it get better exactly? Old software doesn't come sandwiched, ossified between rock strata that can further attest to its obvious age.

Sure it does. :-)

There are lots of things which make it difficult to run really old software on newer platforms, and the more obstacles you place in the way of a notional IRIX Trusting-attack implementor, the less likely you make an outcome positive to him.

> You're still going to have to determine whether or not the bag of bits you have before you really is the same as that old compiler you want to put your faith in. You'll have to trust your md5sum binary (oops) and you'll have to trust MD5. Oops. And you're still trusting the original compiler author.

Yes, but what you're trusting him to do *now* is to have written a compiler which could properly identify and mangle a compiler which did not even exist at that time. And compilers are sufficiently different from each other syntactically that I don't think that attack is possible even in theory, though clearly, "I don't think" isn't good enough for our purposes here. :-).

> The "the old author can't have thought of future compilers" argument seems weak. Viruses are much more sophisticated these days - there's no need the attack has to be limited to specific implementations of software.

Well, I think that depends on which attack we're actually talking about here, and "virus" doesn't really qualify. The Trusting attack was a compiler-propagated Trojan Horse, a much more limited category of attack than "viruses these days", and therefore even harder to implement.

I'm not sure why failing to expect clairvoyance from an earlier-decade's attack author is a weak approach, either. :-)

Countering the trusting trust attack

Posted Feb 5, 2010 21:42 UTC (Fri) by paulj (subscriber, #341) [Link]

Thompson implementing his attack as a compiler attack is a detail, primarily
because source code was the normal form of software interchange but the
basic compiler toolchain obviously still required passing around binaries. In
short it was the *only* place he could have implemented an attack by
subverting binaries. His paper is explicit that the compiler attack is merely a
demonstration of a more fundamental problem of having to place trust in
computer systems. Particularly, he mentions microcode as a possible level of
attack - clearly a completely different thing from compiler level and indication
that Thompson was making a very general point.

To think that Thompson's attack is only about compilers is surely to miss the
point of a classic paper.

Also, I don't expect clairvoyance. Indeed, you miss my point about which
direction the attacker is going.

I think perhaps I should properly write up my criticism...

Countering the trusting trust attack

Posted Feb 5, 2010 21:52 UTC (Fri) by Baylink (guest, #755) [Link]

Because I am a believer in the traditions of science, yes, I think it would be an excellent idea if you wrote up formally your problems with his paper...

which I *promise* I'm going to read, tonight while I wait for a server upgrade to finish. :-)

And certainly any level of the stack can be attacked, and I understand that was his point. But one either has to say "there's no practical way for me to validate the microcode of the CPU, and thus there's a practical limite to what I can verify", or one has to -- in fact -- do that validation.

If one can.

As we note on RISKS regularly, there are two issues at hand here: "pick your own low-hanging fruit", ie: make sure you apply extra security balm equally to all layers of your problem (as adjusted by your threat estimates at each layer), and "know your CBA": the amount of security at all levels you apply has to be in keeping with not only your threat estimate, but with what the bad guys can *get*.

This is, in particular, the part of the issue that terrorists throw monkey wrenches into: trying to inspire asymmetrical responses to what are, objectively, low-level threats. Your opponent wears himself out on the cape and never sees the sword. Bruce Schneier likes to address this issue.

Countering the trusting trust attack

Posted Sep 20, 2010 14:53 UTC (Mon) by paulj (subscriber, #341) [Link]

Took a while, but I wrote up those views on "Diverse Double-Compiling" and stuck them online here.

Countering the trusting trust attack

Posted Feb 5, 2010 23:05 UTC (Fri) by nix (subscriber, #2304) [Link]

Of course paulj's attack is possible in theory. We just need strong AI
first.

Countering the trusting trust attack

Posted Feb 5, 2010 23:03 UTC (Fri) by nix (subscriber, #2304) [Link]

You misunderstand. I'm not saying 'if you prove that this compiler is old
then you will invariably detect the Thompson hack' I'm saying 'if it is
likely that this compiler is old then your chances of detecting the
Thompson hack go way up'.

(And the Thompson hack *was* specifically relating to quined attacks on
compilers and other code generators. Viruses are a much larger field, with
Thompson hacks as a small subset. It is possible they are converging, but
I see little sign of it: attacking compilers isn't profitable because
they're relatively uncommon on the man in the street's machine.)

Countering the trusting trust attack

Posted Feb 10, 2010 9:45 UTC (Wed) by hppnq (guest, #14462) [Link]

So, how about "yum update"? ;-)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds