Re: Reproducible Builds for Fedora

[Alexander Cherepanov <cherepan () mccme ru>]

On 2013-09-27 03:46, Steve Grubb wrote:
> On Friday, September 27, 2013 02:46:33 AM Alexander Cherepanov wrote:
> > On 2013-09-25 18:55, Solar Designer wrote:
> > > Ensuring that "objdump -d" has stayed the same between a known-good and
> > > another build of a binary is not sufficient to tell that the new build
> > > is not trojaned.
> >
> > Indeed. But I think the whole approach is wrong. Attempts to conduct
> > format-specific comparing are futile for several reasons:
> >
> > 1) when you are against a state level adversary (and we are talking
> > about targeted attacks from organizations like NSA, right?) you are
> > better not to try to parse anything complex, like file and objdump do
> > (e.g. crashing objdump is quite easy);
>
> Well, what choice do any of us have? 

The choice is simple -- produce byte-for-byte identical builds. Both Tor
and Debian aim at it.

> I understand the attacker could know a 
> hole in the program doing disassembly or categorization of the file, but I have 
> to assume any bug there will be found eventually as gcc stack protector and 
> other mitigations get better. But we have to have a starting point.
>
> > 2) you cannot really determine format of a file (think GIFAR);
> >
> > 3) an elaborate script which knows many formats is going to be complex
> > and to contain a lot of bugs which is bad in any security context.
>
> I don't believe in giving up. I can verify most rebuilds right now. 

Please don't take me wrong, I'm not proposing to give up or trying to
discourage you. It's great that you are working on reproducible builds.
But we should not fool ourselves regarding the confidence level of
available solutions. Maybe it's better to separate the problem of
reproducing byte-for-byte identical builds from the problem of figuring
the difference out when builds differ.

> When holes 
> are found they get addressed. So far, there has been great feedback on this. I 
> am adapting the detections based on this feedback. It may never be 100% fool-
> proof. The build environment could be thoroughly trojaned or the OS. But let's 
> start in the direction of proof and see what we find.
>
> For example, this tool kit might be of interest where people outsource 
> augmentation of a system and want to check what all the contractor changed. 
> You don't always need to think you are against the NSA to do something that is 
> worthwhile. But, hopefully, its tight enough to catch that threat eventually.

Indeed, the possibility to figure out the difference between two builds
is quite useful.

> > Examples for the item 3:
> >
> > - checks like "/usr/bin/file $2 2>/dev/null | grep ELF" are not strict
> > enough because file sometimes shows pieces of metadata which is
> > controlled by an attacker;
>
> That was changed to a sed '1,2d' which takes care of the same problem better.

You mean the problem with objdump mention earlier by Sebastian Krahmer?
This is another problem.

> > - in a script from opensuse -- at least ".*" in html cleaning permits to
> > pass any html through;
> >
> > - some files are not checked at all: jars in the script from redhat and
> > created.rid in the script from opensuse (.rid extension is not in my
> > /usr/share/mime/packages/freedesktop.org.xml so format will be
> > determined by the OS from content).
>
> This script is under development and not finished. 

Sure, but examples from the more mature script are quite similar.

> I have only setup the 
> detection of jar files with the intent of completing their comparison by 
> unzipping them and doing a file by file comparison and/or further expansion 
> because it could contain more jar files. The whole purpose is to eliminate the 
> inherent time stamp in the file. The next major release should have this 
> solved.
>
> I appreciate the feedback. I want to make it better.

Great, thanks for working on it.

-- 
Alexander Cherepanov