Security Implications of (Non)Reproducible Middleware Builds

biolizard89
Posts: 1933
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Security Implications of (Non)Reproducible Middleware Bu

Post by biolizard89 » Sun Sep 27, 2015 9:54 am

somename wrote:I think it would be better to submit improvements upstream (to Bitcoin Core), then the easier part (adjusting steps for Namecoin Core) could be documented by a Namecoin non-dev (or dev).
Anything that's relevant to Bitcoin Core would be submitted upstream. We're actually pretty militant about avoiding merging anything to Namecoin Core that is better done upstream, for exactly that reason. (The lack of that policy in the past contributed to us having to rewrite NamecoinQ into Namecoin Core.) [1] I'm mainly talking about changing strings in the documentation that are different between Bitcoin Core and Namecoin Core (e.g. the word "bitcoin" in some paths in the instructions).

[1] Actually, some Namecoin developers *might* be okay with merging something like Zerocash without waiting for Bitcoin Core developers, because the way it affects us is quite different from Bitcoin's case. However, this is definitely not a given yet. I personally don't want to make policy exceptions for Zerocash given the current situation; things might change in the future.
somename wrote:Python: I think I pasted links to bugs referred to related to Python (they have been resolved/closed). But then new ones have been discovered (https://wiki.debian.org/ReproducibleBui ... rch=Titles).
Some have already been fixed (https://bugs.debian.org/cgi-bin/bugrepo ... bug=759231) and others have existing workarounds (https://wiki.debian.org/ReproducibleBui ... ionNumbers). Perhaps we're only a quarter away from being able to build deterministic builds on Debian (but not on Ubuntu?).
The bigger problem is building Python reproducibly on Windows. (I'm not sure about OS X.) Mike and Seth's talk discussed a number of reasons why building reproducibly for Windows is important even though Windows itself doesn't build reproducibly. For example, if our builds for Windows are reproducible, that means there's no incentive to compromise our build process for the purpose of attacking some of our Windows users. It is plausible that Microsoft's build process is sufficiently secure that attacking non-reproducible cryptocurrencies is more effective than attacking Windows directly; we can avoid that by having reproducible Windows builds. (I'm not attempting to thoroughly enumerate the advantages of this; Mike and Seth do a much better job than I could.)
somename wrote:While searching for Gitian related stuff I found this: https://www.bountysource.com/issues/841 ... to-bitcoin (a closed issue).
Luke-Jr actually notified us of a related issue to that -- by renaming some of that stuff, we made it impossible for Bitcoin's input cache to be reused in Namecoin. We should fix that. But the original issue is fixed AFAIK, at least for the Linux descriptors (I don't remember if I ever tried the Windows descriptors, and I definitely didn't try OS X).
somename wrote:Few weeks back when trying to build Namecoin Core 0.11 I encountered a related issue (https://github.com/namecoin/namecoin-core/issues/31). Maybe those who use Gitian for both Namecoin and Bitcoin would run into this issue unless they were to take snapshots or clones of their Gitian environments.
I don't think this is likely to be a problem for Gitian. Gitian intentionally starts each build with a clean VM, specifically for the purpose of eliminating any pre-existing factors that might make the build non-reproducible. It's entirely possible that packages built with Gitian will conflict between Bitcoin and Namecoin when they're installed due to that bug, though... I haven't tried that.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

somename
Posts: 80
Joined: Mon Sep 15, 2014 3:12 pm
os: windows

Re: Security Implications of (Non)Reproducible Middleware Bu

Post by somename » Sun Sep 27, 2015 12:47 pm

biolizard89 wrote: The bigger problem is building Python reproducibly on Windows. (I'm not sure about OS X.)
I don't know if you know (I didn't, until couple of weeks ago when I tried to actually use Gitian), but all (Lin, Win, OSX) builds are built on Linux.

josephbisch
Posts: 69
Joined: Sun Nov 23, 2014 3:34 pm
os: linux

Re: Security Implications of (Non)Reproducible Middleware Bu

Post by josephbisch » Sun Sep 27, 2015 2:11 pm

somename wrote:
biolizard89 wrote: The bigger problem is building Python reproducibly on Windows. (I'm not sure about OS X.)
I don't know if you know (I didn't, until couple of weeks ago when I tried to actually use Gitian), but all (Lin, Win, OSX) builds are built on Linux.
I'm sure he meant building Python reproducibly for Windows instead of on Windows.

biolizard89
Posts: 1933
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Security Implications of (Non)Reproducible Middleware Bu

Post by biolizard89 » Mon Sep 28, 2015 7:51 am

josephbisch wrote:
somename wrote:
biolizard89 wrote: The bigger problem is building Python reproducibly on Windows. (I'm not sure about OS X.)
I don't know if you know (I didn't, until couple of weeks ago when I tried to actually use Gitian), but all (Lin, Win, OSX) builds are built on Linux.
I'm sure he meant building Python reproducibly for Windows instead of on Windows.
Joseph is correct. That's why I specifically mentioned cross-compiling. (Somename may be unaware that I've used Gitian to build Bitcoin and Namecoin, and I've written Gitian descriptors, including one for libcoin.)
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1626
Joined: Thu Aug 18, 2011 6:59 am

Re: Security Implications of (Non)Reproducible Middleware Bu

Post by phelix » Mon Sep 28, 2015 6:59 pm

Interesting discussion :)
pmc wrote:IMO reproducible builds of security relevant software make some sense, because less trust is required of whoever publishes pre-built binaries.

There is, however, a point where it stops making sense. That's simply because at some point you have to trust the operating system, the compiler, the libraries, the headers and everything else needed for building. And you have to trust everything that was used to build the OS, the compiler, the libraries and everything else. And so on.

I suppose you know that it's possible to include a backdoor into a compiler that will include itself into every build of that compiler's (unmodified) source code.
pmc nailed it with this post imho.

I have created a Python issue: http://bugs.python.org/issue25255?@ok_m ... plate=item
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

phelix
Posts: 1626
Joined: Thu Aug 18, 2011 6:59 am

Re: Security Implications of (Non)Reproducible Middleware Bu

Post by phelix » Tue Sep 29, 2015 9:05 am

Here is the answer from the Python devs, unfortunately as expected:
E.g. how is it ensured there are no backdoors in the binaries?
Basically through trusting the people who produce the builds.
biolizard89 wrote:
pmc wrote:IMO reproducible builds of security relevant software make some sense, because less trust is required of whoever publishes pre-built binaries.

There is, however, a point where it stops making sense. That's simply because at some point you have to trust the operating system, the compiler, the libraries, the headers and everything else needed for building. And you have to trust everything that was used to build the OS, the compiler, the libraries and everything else. And so on.

I suppose you know that it's possible to include a backdoor into a compiler that will include itself into every build of that compiler's (unmodified) source code.
You're referring to the Trusting Trust attack. That attack is possible to mitigate, by compiling the compiler with multiple compilers (including proprietary compilers) and seeing if the resulting compilers produce the same binary of the application you're building. This only works if your application can be reproducibly built. While this is a difficult problem, it does not mean that people shouldn't work on it. (There are a number of people working on this task.)
Is it realistic for us to achieve this anytime soon, even with Go?
In addition, trusting just the compiler is better than trusting both the compiler and the person who built the application. The goal here is to raise the costs of compromising the resulting binary; decreasing the number of trusted parties is a perfectly effective way of doing this.
Reducing the number of weak links from three to two may not be worth the effort on it's own. It may be better to improve in other places e.g. making it easier for people to build themselves.
somename wrote: If there was a complete and correct working documented procedure for Namecoin Core, I can't see why anyone would be against the effort.
For the record, I am not in the case of Namecoin core. Also I completely agree reproducible builds might be worth some effort in general.
biolizard89 wrote: The bigger problem is building Python reproducibly [for] Windows. (I'm not sure about OS X.)
At a first glance building Python ON windows looks well automated and surprisingly simple. This should help reproducible builds.
Mike and Seth's talk discussed a number of reasons why building reproducibly for Windows is important even though Windows itself doesn't build reproducibly. For example, if our builds for Windows are reproducible, that means there's no incentive to compromise our build process for the purpose of attacking some of our Windows users. It is plausible that Microsoft's build process is sufficiently secure that attacking non-reproducible cryptocurrencies is more effective than attacking Windows directly; we can avoid that by having reproducible Windows builds. (I'm not attempting to thoroughly enumerate the advantages of this; Mike and Seth do a much better job than I could.)
The advantage we have is that attacking Bitcoin (via non reproducible routes) is currently way more effective.

Looking into building the Python interpreter step 1 is:
* Install Microsoft Visual Studio 2015

What a bummer. That will take me some time to digest. I wish it was 2030 and everybody was using Debian.

When I first looked into reproducible builds (for EasyWinBuilder in 2013) I was very naive and had expected it to be standard behavior. This field of computer science is horribly underdeveloped. (With EasyWinBuilder I ended up trying to compare disassembly output - it worked reproducibly to some extend but I never found out if it was secure at all.)

Reproducible builds are interesting to pursue but tbh I am sure there are other things to work on with a security wise benefit/effort ratio factors 10 higher. Nobody should give in to the illusion of reproducible builds giving perfect security. In some cases it might be like installing a large steel door while the windows are open. E.g. the forum needs to be updated (somebody bug Ryan).


edited: grammar, answer from Python guys at the top
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

phelix
Posts: 1626
Joined: Thu Aug 18, 2011 6:59 am

Re: Security Implications of (Non)Reproducible Middleware Bu

Post by phelix » Mon Oct 05, 2015 3:51 pm

One more thing for the record: No matter what we do people will always trust official Python binaries more than our executables.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

Post Reply