Bitcoin Core開発者数名が、Bitcoin Core 24.xとそれ以前のバージョンに影響する深刻な脆弱性を今月中に公表すると発表し、物議を醸しています。脆弱性が内密に報告されたのは１年以上前のことで、現在最新版のBitcoin Coreは27.0となっており、Bitnodes調べでは公開されているビットコインノードのうち70%ほどがすでに対策済みのバージョンで動いています。
ビットコインにおける脆弱性公表は非常にセンシティブな話題です。内容にもよりますが、公表してしまうと大きな金額を支えているネットワークで問題を起こしてみようという好奇心の強いハッカーの関心を集めてしまうことも考えられます。しかも、オープンソースソフトウェアのため、内容を伏せて「脆弱性に対応した」と公表するだけでも変更履歴から内容を探り当てられてしまうため、公表はできればすでに対策が十分に取れた状態まで待ちたいところです。
脆弱性の内容自体はまだ公表されていないので触れることはできませんが、今日はそのあたりの検討事項を軽めに解説します。
また、現在は「脆弱性に対応した」と公表した状態になっているため、読者の皆様におかれましても、Bitcoin Coreでビットコインノードを動かしている場合は最低でもバージョン25.2以上へのアップデートを強くお勧めします。
・Bitcoin Coreにおける脆弱性対応の流れ
・脆弱性の公表タイミングはケースバイケース
・ライトニングノードもアップデートで脆弱性対応が行われることがあるので要注意
Bitcoin Coreにおける脆弱性対応の流れ
そもそも、Bitcoin Coreのバグはどのように報告したらよいのでしょうか？
Bitcoin Coreのウェブサイトによると、GitHubリポジトリののIssue Trackerとセキュリティに関する問題を報告するメールアドレスsecurity@bitcoincore.orgという２つ窓口が用意されています。
公開することで重大な影響があるかもしれない脆弱性は後者のメールアドレスに報告することが良さそうですね。その後の脆弱性対応の流れの例として、バージョン0.16.3で修正されたCVE-2018-17144（DoSおよびインフレーションのおそれがある、トランザクション検証ロジックのバグ）についての報告がサイトに載っています。
まとめつつ引用すると：
2018年9月17日
・問題の当初の報告（この場合は上記メールアドレスではなく、数人の著名なビットコイン開発者にコンタクト）
・コンタクトを受けた開発者らが内容の検証、および対応上役に立つ人物や起業にコンタクト（他の開発者やマイナーなど）
・パッチの公開と報告者への返信
2018年9月18日
・バイナリのリリース、Redditでのアップデート周知
2018年9月19日
・メーリングリストで繰り返しのアップデート周知
2018年9月20日
・別の開発者が同じ問題を（独立して）セキュリティコンタクトメールアドレスに報告
・Bitcoin Core開発者が脆弱性の内容を公表
後日
・Testnetにて脆弱性のエクスプロイト、未アップデートのTestnetノードに障害
このように、重大なバグである場合は対応前にその内容を広く公表するわけにはいかないので、少人数のBitcoin Core開発者で会議と対応が行われていることがわかります。（また、企業との関わりが深い開発者も対応にとって有用である場合は駆り出されているようです）また、対応が速やかに完了した時点で公表が行われており、Bitcoin Core開発者がむやみに脆弱性の公表を先延ばしにしがちなわけではありません。
CVE-2018-17144は有力なマイニングプールの多くが修正すれば早急に対応できる（バグを悪用すると未アップデートのノードからはわからないが、大半のプールがアップデート済であれば不正なものとしてReorgされてしまうため悪用しないインセンティブが働く）ため、開発者が問題発生を回避するために必要な主体にアップデートを働きかけることができたという意味ではラッキーだったともいえます。
ちなみに2017年にbitcoin-devメーリングリストでAnthony Towns氏がBitcoin Coreにおける脆弱性報告や公表の事実上のポリシー（明文化されてはいない）をまとめてくれています。
脆弱性の公表タイミングはケースバイケース
上記のCVE-2018-17144の例では、脆弱性は最初に報告されてからわずか3日ほどで対応が完了し、Full Disclosure（内容も含めた詳細な公表）が行われました。
実際の脆弱性公表のタイミングは「対応の進捗」と「リスク」を天秤にかけて決定されるものであり、ケースバイケースといえるでしょう。いくつかの例を見ていきます。
重要性が高くない脆弱性の場合
あまり深刻でない脆弱性の場合、新バージョンのBitcoin Coreリリース後2週間程度で公表されることがあります。必ずしも即刻のアップデートが推奨されるようなものではありませんが、基本的には最新版を動かすのが良いでしょう。
私も面倒なのでよく放置してしまいますが。
チェーン分岐が発生するなど、現在進行系で問題を引き起こしている場合
こちらも緊急対応が必要なケースです。有名な例で言えば2010年のインフレーションバグです。このときはハッシュレートの半分以上がアップデートしてバグ発生時のブロックから先をReorgすることが目的でパッチが問題発生から5時間以内に公開され、その後半日ほどかけてReorgが実行されました。
上で解説したCVE-2018-17144の対応と同じく、マイナーが十分に対応すればとりあえずは問題解決（マイニングをしないノードによるアップデートは喫緊の課題ではない）という点においては似ていると思います。ただし、当時あまりビットコインネットワークやビットコインノードに依存する取引所などの事業者がいなかったことは特筆すべきで、例えば取引所などがアップデートしていなければ影響を受けていたことは明らかです。
該当期間にマイニングや送受金を行わないユーザーのノードがアップデートされなくても特に問題ではなかったでしょう。
十分な対応がなされたと見なすのに多くのノードのアップデートが必要な場合
これは今回問題となっている脆弱性対応についてです。これまでの例だとブロックの生成に関する問題であり、マイナー同士の相互監視によって不正防止のインセンティブが働きやすいという特徴からとりあえず大手のマイナーに対応してもらえればリスクがほとんどゼロになる、という特徴がありました。
ところが、逆に問題がネットワーク規模だとどうでしょう。例えばノードに任意で他のノードとの接続を遮断させられるようなバグがあれば、いわゆるNetsplitといった形でビットコインネットワークを分断したり、特定のノードを孤立させたりできるかもしれません。このようなネットワークの側面での脆弱性だと、マイナーだけでなく大半のノードがパッチ適用済みのバージョンに乗り換えるまで脆弱性の内容を秘密にしておく必要があります。
ビットコインノードはソフトウェア的に非常に安定しているため、稼働させたまま１年以上放置するユーザーも少なくないというのがこのようなケースにおいて対応の遅さにつながりやすいという問題もあります。冒頭でも述べましたがBitnodesによると30%ほどのノードはまだバージョン24.x以前を使用しています。
ライトニングノードもアップデートで脆弱性対応が行われることがあるので要注意
ライトニングノードもときどき脆弱性対応が発表されています。
例えばLndはバージョン0.11でいくつかのバグが修正されました。これは一部のケースにおいて誤ってプリイメージが流出してしまうバグであり、早急な対応が必要なものでした。2020年4月19日にLnd開発チームに報告後、7月31日に修正版(v0.11.0)のリリース、10月8日に部分的な公表とユーザーへのアップデート推奨、10月20日にFull Disclosureというタイムラインで進められました。
ライトニングノードのアップデートはバグFixなども多いため積極的にしていきたいところですが、個人的にはリリースから1週間以上は待ってからするようにしています。新たなバグや既存のノードとの互換性でチャネル閉鎖が起こった事例などもあるため、そのような報告が多発していないか確認するためです。
例えばLndではアップデートによってバージョンが違うLndとのチャネルが強制閉鎖されてしまう問題が置きたりしました（v0.12.1などで）。CLNにおいても、CLN 0.11.1が多くの強制閉鎖を発生させてしまいました。このように高コストなハプニングが誘発されないか確認してからアップデートするようにしたいところです。
おまけ
これまでにビットコインやライトニング関連でCVE（共通脆弱性識別子）が発行されたものの一覧はこちらにあります。
次の記事
読者になる
一緒に新しい世界を探求していきましょう。
ディスカッション