Re: Building packages with exact binary matches
On Thu, Sep 27, 2007 at 06:31:58PM -0500, Manoj Srivastava wrote:
> On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker <muecker@gmx.de> said:
[...]
> >> But recompiling from what? If you do not get the exact same source,
> >> you have no hope of getting the same result.
>
> > I had the impression that Debian distributes the source code from
> > which the binaries are actually compiled and not some random
> > variation.
>
> Yup, complete with all the trojans in the binary and all.
You are seriously stating that is as easy to hide a trojan in
the source code as in the binary? I have seen a lot trojans
hiding in binaries but I have never seen that an open source
project distributed trojaned source code. Maybe they where such
incidents but there are certainly rare.
> >> And the way things work, the chances are that if the binary is
> >> tainted, the source would be tainted -- and you have got nowhere.
>
> > If I wanted to hide a trojan somewhere I would to it in the binary and
> > not in the source code. People actually look into source code on a
> > regular basis but they seldom disassemble a binary.
>
> The window of opportunity is small. You have to replace the
> binary .deb in between the time it was built, and it was signed.
That's a small window if you measure the time but it is not
small window of opportunity. If the building host is compromised
than it is trivial. And it seems that DDs do upload binaries
which are compiled on their local machines. So it is actually
enough if any of those machines is compromised.
[..]
> >>
> >> So, someone replaces the binary compiled on the buildd with a fake
> >> one, in between the binary being built and it being signed? All the
> >> work to get bit-for-bit reproducibility for such a low priority
> >> attack vector?
>
> > I do not think it is a low priority attack vector. If I would be a
> > cracker and had a rootkit installed on a debian build host it would
> > certainly insert a backdoor in ssh everytime it is compiled: Access to
> > all debian running computers world wide!
>
> Compromise gcc? I see. So, fro all you know, every copy of gcc
> in the world now has the compile trojan into ssh built in, and again,
> no way for people peering at bits to see if there is a trojan buried in
> there to find out.
Why all copies of gcc? A single copy of a gcc on a single host where
official debian packages are compiled. And the gcc binary on the disc
is unmodified: The compiler is patched after loading it in the memory
by a rootkit. Not that a single binary copy of gcc was ever completely
dissassembled and checked for trojans. That would probably take at least
a year to do.
> > BTW I did some tests and for 'dpkg' the only files which change
> > between builds are the manpages and that's just because gzip stores
> > the date of the orginal in the compressed file.
>
> This is one of the things, yes. ANy package with a tar archive
> would suffer similarly.
That all files which are created by the actualy build process are already
bit-identical (for dpkg) and only a postprocessing step adds time stamps
is very promising, I think.
Martin
Reply to: