Warning: No crypto or other excitement inside.
I've been working on making the way the Monero command line tools are released better. This includes easier recipes for building on Windows, the ability to cross compile to any of the currently supported architectures and operating systems on a Linux, or macOS machine with depends, ensuring that libraries used in Monero do not use proprietary components and making Monero binaries reproducible with gitian.
Then end goal of my project is protecting Monero from a watering hole attack. A watering hole attack describes a class of attacks where a tool or binary that is used by a particular group of people is compromised. There are multiple ways to protect a binary from containing malicious, or unintended bytecode.
Foremost it is important to use dependencies that have been compiled from source during the build process. Dependencies should be taken from a source that publishes them directly. This ensures that no 3rd party distributor (software vendor), like sourceforge, who have a track record of shipping adware with its published binaries, messes with the binary in any way. This also lets you finely choose which version of the dependencies you want to use, to ensure you are patched against any recently discovered vulnerabilities of your dependencies.
In past releases Monero already did a decent job with this. The msys packages for windows and brew packages for mac can all be compiled from source. It is also important for a cryptocurrency that releases can be done as quickly as possible, and released binaries should be updated fast. Recent events have shown us, that the security of Monero greatly relies on getting patches out as quickly as possible.
Releasing patched binaries should not be a process that relies on a single, or a small group of developers all being available the entire time. Especially in a system that should be as anti-fragile as possible, developer up time should not be a guarantee. More people should be able to compile release builds of the Monero software and everybody should be able to verify that the release only contains the compiled source code.
Though the current Makefile in the Monero git repository contains commands like make release-static that should be able to do this, practice has shown that the process is confusing and people end up using wrong versions, or misconfigured dependencies (the good old have you compiled with -fPIC? spiel).
When I currently compile Monero version 0.13, my compiled binaries will be different from the published release binaries on getmonero.org. They will have different checksums, meaning I can not be sure if the binaries distributed there contain altered bytecode, or not. This is, because the tools used are not consistent with producing binaries. They place system paths, timestamps and debug symbols in different places of the bytecode depending on the system used. It is however possible to design systems in a way that produce binaries in a consistent manner. Bitcoin and tor use a system called gitian to achieve this. The process of doing this is called reproducible builds.
Reproducible builds allow many developers to collaborate on a build. Some projects have thresholds, where releases are only made when at least three independent developers have produced binaries with matching checksums. The process also allows users to make sure that the binary released is indeed consistent with the source code by matching checksums with the locally compiled binaries with those of the published binaries. When patches need to be released quickly, binary integrity can be proven at a later stage.
All the steps above already decrease the chance of a watering hole attack.
This scheme is still not perfect though. It requires a lot of manual interaction by both developers and users. Still, it does not eliminate all trust, since dependencies and compilers used still need to be trusted. In the end all it ensures is that binaries are compromised in the same way. Currently, there is research being done into 'Transparent Binaries', which would further improve the build environment and make it much easier for people to verify. Information on this can be found on the mozilla wiki and this paper by Tflow.
No comments:
Post a Comment