Re: Time to resurrect multi-key signatures in RPM?

[David A. Wheeler]

Les Mikesell:
> And if you are really paranoid you have to wonder about the compiler
> and
> any existing libraries too: http://cm.bell-labs.com/who/ken/trust.html. 
I'm actively working on techniques for countering malicious compilers/libraries;
I even had a paper published by ASCAC on the topic:
http://www.dwheeler.com/trusting-trust/
(The example in the paper was run on Fedora.)

Unsurprisingly, it requires determinism (e.g., recompiling the same
program with the same compiler, on & for the same architecture,
produces the same binary).

This kind of determinism is not something that should be
_required_ for Fedora 10, but it'd be a good thing to shoot for.
Determinism is good for testing & debugging, anyway.  If the compiler,
running on the SAME architecture, generates different code when you
re-run it, some kinds of compiler bugs are devilishly hard to track down.

--- David A. Wheeler

Time to resurrect multi-key signatures in RPM?

[Bojan Smojver]

David A. Wheeler <dwheeler <at> dwheeler.com> writes:

>  Unsurprisingly, it requires determinism (e.g., recompiling the same
>  program with the same compiler, on & for the same architecture,
>  produces the same binary). 
As you say:
-----------------
  $   # If a.out and a.out.saved are always identical (except internal
  $   # timestamps, if any) then the compiler is deterministic.
-----------------

And I could almost swear it is also possible to (automatically) edit binaries
that are different due to different environments (i.e. think things that embed
uname -v, perl -V etc.) so that a baseline is established and _then_
checksummed, giving the correct (i.e. relevant) comparison.

--
Bojan

Time to resurrect multi-key signatures in RPM?

[Nils Philippsen]

On Thu, 2008-08-28 at 21:15 +1000, Bojan Smojver wrote:

>  But look, it is obvious that we (and by this I mean myself and the
>  majority of people in the thread) have fundamentally contradicting views
>  about this, so let's agree to disagree, OK? I don't want to drag this
>  forever.
>  
>  Consider my proposal withdrawn. 
Even if it looks differently, I've not been trying to shoot anything
down -- I'm just not that good at phrasing criticism so that it's
received as constructive... Let's see if I can add something positive:

On Thu, 2008-08-28 at 23:25 +0000, Bojan Smojver wrote:
>  David A. Wheeler <dwheeler <at> dwheeler.com> writes:
>  
>  > Unsurprisingly, it requires determinism (e.g., recompiling the same
>  > program with the same compiler, on & for the same architecture,
>  > produces the same binary). 
The exact build state, not only the compiler, would have to be
replicated for that, as there could be code inlined from headers etc.
that influences what ends up in the binary. E.g. when building, save
info about all installed packages (envr, md5sums, maybe even rpm-verify
it for cross-checking?). Build "reproducers" would have to use the exact
same versions for reproduction attempts.

Keep in mind that this can lead to false negatives, i.e. if all
reproducers use the same compromised compiler package that someone
managed to sneak in -- this could realistically only show attacks on the
build system itself. I'm not sure how to tackle that, perhaps by
employing a not so rigid setup where all reproducers would _not_ use the
exact same versions, but the process would not immediately block
shipment, but flag differences so people can look into them.

>  As you say:
>  -----------------
>    $   # If a.out and a.out.saved are always identical (except internal
>    $   # timestamps, if any) then the compiler is deterministic.
>  -----------------
>  
>  And I could almost swear it is also possible to (automatically) edit binaries
>  that are different due to different environments (i.e. think things that embed
>  uname -v, perl -V etc.) so that a baseline is established and _then_
>  checksummed, giving the correct (i.e. relevant) comparison. 
I think that's a bit dangerous as malicious code could be designed in a
way that it's edited out before checksumming (make it look like you've
incorporated the kernel version).

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

Time to resurrect multi-key signatures in RPM?

[Bojan Smojver]

On Fri, 2008-08-29 at 12:07 +0200, Nils Philippsen wrote:
>  Build "reproducers" would have to use the exact
>  same versions for reproduction attempts. 
We keep the logs in Koji that tell us what versions and releases of
packages were used to build things.

>  Keep in mind that this can lead to false negatives, i.e. if all
>  reproducers use the same compromised compiler package that someone
>  managed to sneak in -- this could realistically only show attacks on the
>  build system itself. 
Of course. The aim of this would only be prevention of a compromised
build system and/or compromised Fedora key causing a distro wide
disaster.

Compromised source of an uploaded package and especially trojaned
compilers are entirely different problems and are mostly beyond the
scope of what distributed trust model is about (as presented here).

I was only using David's compiler comment to illustrate that it is a
good thing for a build to be deterministic. David seems to have
developed a pretty good technique for tackling trojaned compilers (which
distributors should be using regularly, IMHO).

>  I think that's a bit dangerous as malicious code could be
> designed in a
>  way that it's edited out before checksumming (make it look like you've
>  incorporated the kernel version). 
I would say that people that are capable of injecting malicious
instructions streams into binaries of disparate CPUs that always read
"2.6.25.14-108.fc9.i686" should be employed immediately ;-)

But seriously, yeah, there is some danger in that. We could also rely on
some kind of elfdiff or something else instead. There are ways.

-- 
Bojan