今週は読者からの質問コーナーです。

Bitcoin CoreやUmbrelなどのアップデートについて、すぐに最新に更新するべきか、それとも重大な脆弱性解消があるかどうかを確認した後にアップデートすべきか、なければ暫く様子を見るべきかのかいつも迷いながら雑に運用しています。
リリースノートを参照すべきなのでしょうが、それも疎かにしています。どのように運用するのが適切でしょうか。

ビットコイン関連のソフトウェアアップデートには重要な脆弱性修正が含まれていることもあれば、逆に脆弱性が含まれている可能性もあるでしょう。理想的には変更の内容を自分で検証、少なくともリリースノート(チェンジログ)くらいは確認したいところですが、技術的な知識が限られている場合はどのようなアップデート戦略をとればよいのでしょうか?

今日はUmbrelアプリやBitcoinノードのアップデート戦略を考えてみます。

・アップデートは早すぎても遅すぎてもリスキー

・チェンジログは見るべきだが、必ずしも内容すべてが書かれているとは限らない

・個人的におすすめのアップデート戦略

アップデートは早すぎても遅すぎてもリスキー

今回の質問者がご存じの通り、アップデートには脆弱性の修正が含まれている場合や新たな脆弱性につながるバグが含まれていることがあります。

本当に緊急でアップデートが必要な場合はSNSやウェブサイトなどで告知がされている場合がありますが、そういうときに「ひょっとしたらアカウントが乗っ取られているのかも」と疑うのも大事なことなので、すぐにアップデートに飛びつくのが賢いとは思いません。また、このようなシチュエーションは比較的珍しく、脆弱性修正はしれっと行われることが大半です。(このように緊急告知されるのはそのまま使用することが重大な損失につながりうる、かつ悪用可能な攻撃というよりはセルフGOXにつながる脆弱性があるものに限られる印象です。)

逆にアップデートを何年も放っておくと、知らない間に重要な脆弱性の修正と、その後のその事実の公表が経過してしまい、攻撃方法が公に知られている脆弱なソフトウェアを動かしていることになってしまいます。これは非常にまずい状況です。

では、「ちょうどいい」待機期間はどのくらいでしょう?最近の事例から見てみましょう。

例えばLndでは昨年6月に開発チームに内密に報告されたOnion Bomb脆弱性というものが4か月後の昨年10月にv0.17.0によってサイレント修正され、さらに8か月後の今年6月にv0.18.0のリリースとともに脆弱性があったと公表されました。

Lndの「Onion Bomb」脆弱性を公表すべきタイミングはいつだったのか
先週に引き続き脆弱性公表ネタとなってしまいますが、今週はLnd 0.17.0で修正されたバグについてです。今回の内容はいつ公表すべきであったか賛否両論を呼ぶものかもしれません。 その名も「Onion Bomb」と呼ばれているこの脆弱性は第三者が任意のLndノードに対してOut Of Memory (OOM)によるクラッシュを誘発することができるというものでした。約1年前に報告されたこの脆弱性は先日やっと公表されました。 修正版であるv0.17.0は昨年10月にリリースされ、その後Bitcoin Core 27.0に対応したパッチであるv0.17.5までマイナーリリースが続いています。また、先月末にv0.18.0がリリースされ、今回の公表に至ったとのことで、読者の皆様もLndを動かしている場合はv0.18.0またはv0.17.5へのアップデートをおすすめします。 ・脆弱性の内容はシンプルに攻撃可能 ・ノードがダウンすることによるLN特有のリスク ・今回の公表タイミングは妥当か?

これに関しては(2回のメジャーアップデートを挟んでいるとはいえ)1年間も重大な脆弱性を公表せずにいたことが批判されており、私も同感です。しかし、脆弱性を公表せずに修正するにはメジャーバージョンアップのように多数の変更がある中にしれっと紛れ込ませるのが一番安全ですし、ライトニングノードをそう頻繁にアップデートする人が多くないことも直観として理解しているため、将来的に公表までの期間が短縮されたとしても90日を下回ることはないように思います。現実的な落としどころとして報告から4~6か月でしょうか。

したがって、アップデートをチェックする間隔としては1~3か月ほどまでなら多くの場合問題ないかと思います。もちろん、大きな金額を扱っているならより慎重に(頻繁に)確認するのがよいでしょう。

本稿の最後の章で個人的におすすめのアップデート戦略をより掘り下げてみます。

チェンジログは見るべきだが、必ずしも内容すべてが書かれているとは限らない

次に、技術的な知識が足りなくてもアップデートの内容を精査できるのかというと、当たり前ですが現実的な限界はあります。仮に技術的な知識が十分にあったとしても、複数のソフトウェアを使っていてそれを全部レビューしていくのはかなりの時間と労力が必要であるため、理想的とはいえあまり現実的ではないでしょう。(そこまでするくらいなら1つのソフトウェアに絞って、開発に貢献するほうが魅力的に映る人も多そうです)

しかし、リリースノートにあるチェンジログは必ずしも深い技術的知識がなくとも理解できます!もちろん理解できない部分もあるかもしれませんが、そこは飛ばしてもOKです。重要なのはざっくりとした内容(「何を目的にアップデートするものなのか」)を把握することです。特にBitcoin CoreやLndなど以外のアプリケーションであれば簡単だと思います。

簡単な例として、mempool.spaceアプリのv3.0.0のリリースノートを見てみると:

・新機能の追加が多数

・改善や最適化が多数

というのがわかります。この中に気になるものがあればアップデートしてもよいですし、なければそのままでも構いません。強いて言えば、mempool.spaceアプリはトランザクションの署名をしないアプリなので勝手に送金されるようなバグは入る余地がないと思われるので、あまり深く考えずにアップデートしてもよいでしょう。

逆に難しい例だと、Bitcoin Core 28.0のリリースノートです。まずレイアウトから読み取りにくいですが、Notable Changes欄を見ると:

・GUIへの変更が2つ

・ウォレットに新機能追加がいくつか

・REST API、JSON APIへの変更

・ビットコインノードについての技術的な理解が必要な内容が多数

と、一目で見てメリットがわかりにくいかもしれません。もっと言えば、Bitcoin Coreを直接叩いて使うユーザーは少数派で、ここに追加された機能が様々なウォレットのGUIで活用されるようになるまでまだ時間があります。

しかしやはり先月公表されたBitcoin Coreの脆弱性(ノードをクラッシュさせられる可能性がある)はv25.0で修正されていたので公表まで時間がかかりましたが、これからは脆弱性対応ポリシーが変更になったため中程度・重大な脆弱性は影響を受ける最新のリリースがEOL(リリースから1年)を迎えた2週間後に公表することになったので、Bitcoin Coreも新バージョンが出たら早めに乗り換えるのがよさそうです。

Bitcoin Coreの脆弱性はどう公表すべきか?
Bitcoin Core開発者数名が、Bitcoin Core 24.xとそれ以前のバージョンに影響する深刻な脆弱性を今月中に公表すると発表し、物議を醸しています。脆弱性が内密に報告されたのは1年以上前のことで、現在最新版のBitcoin Coreは27.0となっており、Bitnodes調べでは公開されているビットコインノードのうち70%ほどがすでに対策済みのバージョンで動いています。 ビットコインにおける脆弱性公表は非常にセンシティブな話題です。内容にもよりますが、公表してしまうと大きな金額を支えているネットワークで問題を起こしてみようという好奇心の強いハッカーの関心を集めてしまうことも考えられます。しかも、オープンソースソフトウェアのため、内容を伏せて「脆弱性に対応した」と公表するだけでも変更履歴から内容を探り当てられてしまうため、公表はできればすでに対策が十分に取れた状態まで待ちたいところです。 脆弱性の内容自体はまだ公表されていないので触れることはできませんが、今日はそのあたりの検討事項を軽めに解説します。 また、現在は「脆弱性に対応した」と公表した状態になっているため、

例えばv27.0は2024年4月にリリースされたので来年4月以降に関連する脆弱性が公表される可能性があります。逆に言えばそれまでに修正を行うということなので、1つのバージョンごとにアップデートしていくのが最適でしょう。

個人的におすすめのアップデート戦略

個人的に(厳密に守っているわけではありませんが)実践しているアップデート戦略を説明します。

まず、ソフトウェアを「金銭的リスクのあるもの」「金銭的リスクがない・小さいもの」に分けます。これはBitcoin/LNノードとmempool.spaceアプリと明確に区別することもできますし、入っている金額が非常に少なければLNノードなんかも後者に振り分けてもそれほど問題ないでしょう。

(ただし、マルウェア等が仕込まれていたら後者が前者にリスクを及ぼす可能性もあるので、ある程度の慎重さは必要です!)

金銭的リスクのあるもの

遅くとも3か月ごとに新バージョンがあるか確認する。新バージョンが出ていて、1週間以上経過していれば更新する。マイナーアップデートは比較的リスクが低く、コスパの良いバグ修正が含まれていることが多いので積極的に更新する。

本当は内容を見て判断できればよいが、技術的に難しいことと、据え置いて半年以上経過すると脆弱性公表によるリスクが増加するため、ある程度周りに判断をゆだねる。(そのための1週間経過要件)

金銭的リスクのないもの

思い出したらアップデートが出ているか確認する。あるいは、金銭的リスクのあるものをアップデートしたついでに確認する。

アップデートすべきかは内容をみて判断する。SNSなどで確認できれば一番だが、アップデートしてから期間が経っていてもあまり問題はないのでほしい新機能が追加された、あるいは深刻な脆弱性対策が行われたとかでなければ更新しなくてもよい。

自分はこれくらいの方針でいろんなソフトウェアを運用しています。まとめると2点です:

・Bitcoin CoreやLNノードは遅くとも3か月ごとに確認して、新バージョンがリリースから1週間以上経過していればアップデートする。チェンジログはわからないなら見なくてよい。

・それ以外は積極的にアップデートしなくてよいが、深刻な脆弱性対策や欲しい新機能の追加には対応していきたい。そのためにチェンジログは見る。

参考になれば幸いです。自分の方針を披露したい方、ご指摘ある方はぜひコメント欄へどうぞ。

ビットコイン研究所では読者の皆様から匿名で質問を受け付けています。質問フォームはこちらになります:

Form

今回の質問者様、ありがとうございました。