Mozilla project keeps compromised apps out of circulation

Mozilla has long used its Firefox browser as a staging platform for other innovations. One of the first real-world applications for its fast-and-safe systems language Rust, for instance, is rewriting some of Firefox’s innards.

Now comes a project called Binary Transparency, an effort to ensure that every Firefox binary produced by Mozilla is the same one that everyone else has received and hasn’t potentially been tampered with.

At first this sounds like a glorified version of using hash signatures or checksums, which most every organization that supplies binaries of its apps does. But Mozilla has a more ambitious plan: To make it difficult for anyone to distribute compromised copies of an application, even if they come from Mozilla.

Can’t touch this

Mozilla’s plan, documented in a wiki entry, expands on the existing processes for generating checksums from Firefox binaries. First, a hex string from a composite of the checksums of each binary component is generated, then that hex string is used as a domain name. Mozilla then obtains an X.509 certificate from a certification authority using that domain name and posts the certificate in a public log.

With this method, instead of generating a checksum for the binary and posting it somewhere (that is, a wiki), there’s an irrevocable record of the checksum made available by authorities not affiliated with Mozilla. This not only ensures that users downloading a new copy of Firefox don’t get smacked with a bogus binary, but also gives Firefox’s updater a mechanism it can use to make sure it doesn’t unwittingly fetch a maliciously crafted payload.

Fans of blockchain technology will see a kindred concept here. Mozilla is taking data about its binaries and putting it into a (theoretically) immutable public ledger. By using certification authorities, Mozilla works with a familiar entity that has plenty of infrastructure to support its use.

Certified copies

Mozilla’s efforts with tamper-proofing also is a prelude to even more ambitious integrity checks. One of them is providing reproducible builds of Firefox to guarantee that the binaries produced for a specific application came from a given, verified source code tree and not from one that’s been altered.

It’s harder than it might seem to guarantee such bit-exact software builds. Even an item as innocuous as a timestamp on a file can produce an entirely different checksum for the whole package, so the entire build system has to be designed to take such factors into account.

The reproducible build concept is not new, but there’s been a resurgence of interest in making reproducible builds a practical and standardized concern. The Linux Foundation’s CII (Core Infrastructure Initiative) renewed financial support for such a project last year. Many free software projects, from Linux distributions (Debian in particular) to trusted applications like the bitcoin clients or the Tor browser, employ reproducible build strategies. Google’s Bazel build tool, open-sourced in 2015, supports reproducible builds as part of its mission statement.

Getting Firefox to use a reproducible build system has been on the agenda since 2013, but not as a high-priority item, in big part because Firefox’s build system isn’t currently designed to allow it. One issue in particular that creates problems is PGO (profile guided optimization), which optimizes binaries based on details gleaned from running the application. It’s theoretically possible to make PGO play nice with reproducible builds, but like reproducibility in Firefox, it’s a work in progress.