やってみる（Buy-in）

再現性のあるビルド に取り組んでみると、やることは多くても見返りが少ないように感じる場合があります。 セキュリティに関連するさまざまな作業がある からなのですが、再現性のあるビルド の重要性についてさまざまな意見や証言があります。

攻撃に抵抗する

2015年3月、インターネットメディアの Intercept は、Snowden のリークした Strawhorse: Attacking the MacOS and iOS Software Development Kit に関する internal CIA conference in 2012 の講演の概要を 公開 しました。 概要では、匿名の研究者が XCode の改造版を作成する手法を具体的に説明していました。 開発者に気付かせることなく、コンパイル済みのアプリケーションへ任意の透かしやスパイウェアを混入させることができるというのです。

それから数か月、”XcodeGhost” と呼ばれるマルウェアが発見されました。 攻撃対象になってしまった開発者は、知らない間にマルウェアを組み込んだ iOS アプリケーションを配布してしまうのです。 Palo Alto Networks は次のように説明しています。

XcodeGhost は OS X においてコンパイラを対象にした初めてのマルウェアです。 Mach-O オブジェクトファイルにした悪意のあるコードを、特定のバージョンの Xcode のインストーラーへ再パッケージしていました。 この悪意のあるインストーラーは、中国の iOS/OS X 開発者が利用する Baidu Cloud のファイル共有サービスへアップロードされていました。

再現性のあるビルド はまさにこのような攻撃に抵抗するためのものです。 きれいなコンパイラでアプリケーションを再コンパイルすれば、例えば余分なペイロードによるサイズの差異のように、問題を容易に発見できるのです。

Mike Perry と Seth Schoen は 2014 年の 12 月に 31C3 の講演 でこの件について解説しました。 すなわち、疑わしい差異はさらに分かりにくくなり、たった1bitの差異でリモートエクスプロイトできるセキュリティホールを作成できてしまうのです。 Seth Schoen はカーネルレベルのマルウェアを用いて、痕跡を何もディスクに残さずに、コンパイラの読み取るソースコードへ悪質なコードを混入させるところを実演しました。 私たちが知る限り、このような攻撃が実際に観測された記録はありません。 再現性のあるビルドは早期にこのような攻撃を検出する唯一の方法なのです。

品質保証

標準テストに求められるのは、さまざまな環境でソフトウェアのビルドに再現性があることを保証することです。 Debian や他のフリーソフトウェアディストリビューションに求められるのは、ユーザーが自分でソフトウェアをビルドして、配布できることです。 標準テストが役立つのは、ソースコードからビルドできない バグを回避することや、タイミングや競合条件、ロケールなどの影響で稀に発生する、発見の難しいビルドの問題を特定することです。

プロジェクトの開発が活発で無くなってからも、ビルド環境は進化していく場合があります。 Debian では、影響力が強いだけでなく検出の難しいバグを発見するため、さまざまな環境でテストビルドをするようにしています。 おかげで、ビルドするたびに ABI が変化するライブラリを発見しました、文字エンコーディングの不一致により文字化けが発生しました、翻訳が不足しています、依存対象が変化しました、のようなバグを発見しています。

ビルド環境を考慮しなければならないという制約は、外部のソフトウェアやデータ提供者との関係性について、開発者が考えるのを助けています。 代替策を用意せず外部の情報源に依存していると、将来的に深刻な問題を引き起こす原因になります。

再現性のあるビルドは、分散ビルドで照合に使用する デバッグシンボル も同一になるため、再作成が可能になります。 これは、本番環境で使用するソフトウェアで発生した問題を理解するのに役立ちます。

バイナリレベルの差異が小さくなる

再現性のあるビルドでは、ソースコードやビルド環境（例えばコンパイラのバージョン）を変更しただけで、生成されたバイナリが変化することになります。 アーティファクトの変化は最小限で済むので、ストレージに対する要求や、差分を転送するネットワークトラフィックを縮小できます。

アーティファクトが似通っているなら、テストでは未変更のコードに対する信頼を保ちつつ、変更した部分に集中できることになります。 品質保証活動や開発作業の速度は向上します。

ビルドシステムの変更をテストするのも簡単になります。 生成するアーティファクトが同一なら、変更した内容は実行時の振る舞いに影響を与えていないことになるからです。

開発速度の向上

あるパッケージの再ビルドが決して異なる結果を生成しないなら、依存対象のパッケージを再びビルドする必要は無くなりますし、依存対象のタスクを再び実行する必要もありません。 ビルド時間を大幅に短縮できるし、開発速度の向上や、コストの減少につながります。

クロスコンパイルによってネイティブコンパイルと同じ結果を生成できるなら、ビルド速度も向上します。 クロスコンパイルの必要なほとんどのビルドを、より高速なマシンで実行できるようになるからです。

“どうすればコンパイラを信用できますか”

全員が同じバイナリファイルを使っているビルド環境で、環境が汚染されていないことをどうやって確認すればいいのでしょう。 あるいは、ビルドに使用したコンパイラがバックドアを仕掛けていないことをどうやって確認すればいいのでしょう。 再現性のあるビルド に関する一般的な疑問です。

後者の疑問について、1984 年に Ken Thompson の執筆した Reflections on trusting trust がよく知られています。 前述の “Strawhorse” に関する講演の概要でも、この論文について言及していました。

David A. Wheeler が研究し、定義した Diverse Double-Compilation という技法が知られています。 おそらくこれらの疑問の答えになるでしょう。 どういう技法か簡単に整理します。 2種類のコンパイラがあるとします。 信頼できるバイナリと、テスト対象のバイナリです。 テスト対象のコンパイラは2回ビルドします。 まず、信頼できるコンパイラでテスト対象のコンパイラをビルドします。 それから、ビルドしたコンパイラで、もう1度同じテスト対象のコンパイラをビルドします。 最初にビルドした結果と次にビルドした結果が一致すれば、コンパイルの途中にバックドアが仕掛けられていないことが証明できます。 再現性のあるビルド の有用性を説明する好例です。

他のリソース

次の記事が主張している意見も参考になります。

• Cyberwar and Global Compromise by Mike Perry from the Tor Project, 2013-08-20
• Software Transparency: Part 1 by yan, 2014-07-11.

---

← Documentation index

Documentation home

Introduction

• 定義（Definitions）
• History
• やってみる（Buy-in）
• 計画する（Making plans）
• Academic publications

Achieve deterministic builds

• SOURCE_DATE_EPOCH
• 確実なビルドシステム（Deterministic build systems）
• 揮発性のある入力データは消える場合がある（Volatile inputs can disappear）
• 入力データの順序を固定する（Stable order for inputs）
• 値を初期化する（Value initialization）
• バージョン情報（Version information）
• タイムスタンプ（Timestamps）
• タイムゾーン（Timezones）
• ロケール（Locales）
• アーカイブのメタデータ（Archive metadata）
• 出力データの順序を固定する（Stable order for outputs）
• 無作為性（Randomness）
• ビルド時のファイルシステムパス（Build path）
• システムイメージ（System images）
• JVM

Define a build environment

• ビルド環境に含む要素（What's in a build environment?）
• ビルド環境を記録する（Recording the build environment）
• ビルド環境の定義における戦略（Definition strategies）
• Proprietary operating systems

Distribute the environment

• ソースコードからビルドする（Building from source）
• Virtual machine drivers
• Formal definition

Verification

• Cryptographic checksums
• Embedded signatures
• Sharing certifications
• Rebuilders

Specifications

• SOURCE_DATE_EPOCH
• BUILD_PATH_PREFIX_MAP (WIP)