先週に引き続き脆弱性公表ネタとなってしまいますが、今週は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特有のリスク

・今回の公表タイミングは妥当か？

脆弱性の内容はシンプルに攻撃可能

ライトニング関連のバグを多数解説しているMatt Morehouse氏のブログにOnion Bomb脆弱性についての記事もあり、非常にわかりやすかったためそちらを参考に日本語で説明します。

まず、ライトニングノードは送金を中継する際や受け取る際に「Onionパケット」という情報を受け取ります。これは各ノードの公開鍵を使って暗号化されているもので、暗号化されていることによってライトニングのプライバシーが担保されています。（中継ノードが送金元や最終的な宛先を知らないのは直前と直後のノード以外の情報がこのように暗号化されているためです）

このOnionパケットには暗号化された経路情報（payload）とそのサイズを表す数値（length）が含まれていますが、なんとv0.17.0より前のLndはこのpayloadのサイズを実際に確認せずに「とりあえずlength分のメモリを確保する」という挙動になっていました。そのため、lengthの値がが8バイトで表せる最大値（4,294,967,295）であるOnionパケットを送りつけることでメモリ4GBまでのマシンであれば（Onionパケットが実際は大きくなくても）即時にメモリ不足のエラーを引き起こせるわけです。

Lndが使っているGoという言語には余分なメモリ消費を発見次第解消するガベージコレクションという機能があるため、4GBを超えるメモリを有するマシンであればその後このメモリは解放されるため問題は起こらないように思います。しかし、ガベージコレクションが走るまでの短時間で同時に複数のメッセージを送りつけることで最大でメモリ128GBまでのノードをクラッシュさせられたそうです。さすがにこれより多量のメモリを積んだノードを運用しているユーザーはほぼ皆無でしょう。

ノードがダウンすることによるLN特有のリスク

さて、このシンプルな攻撃で未対策のライトニングノードをクラッシュをさせられることがわかりました。ではこの手法を使って任意のノードをダウンさせる動機は考えられるのでしょうか？

まず前提として、ライトニングノードはブロックチェーンを監視することでチャネルを共有する相手の不正を防止しています。ライトニングにオンライン要件がある（一定期間以上オフラインでいてはいけない）のはこのためで、不正行為が発生したら1週間以内であればそれを罰するトランザクション（ペナルティトランザクション）を配信することができるという形でセキュリティを実現しています。

言い換えると、一定期間オフライン状態が続くと、理屈の上では攻撃に遭っている可能性があります。

今回の脆弱性の場合、例えば復帰に時間がかかると予想されるノードに対する攻撃が考えられます。例えば頻繁には使っていないノードの場合、落ちていたことに1週間以上持ち主が気づかないこともあるでしょう。何回か攻撃を試して、どれくらいで復帰するか記録していき、短時間で復帰したことのないノードを有望な攻撃対象として狙うことも考えられます。

対策

逆に言えば、すぐに復帰してしまうノードは今回の攻撃を使っても金銭を盗まれることはありません。ノード自体が起動する際にブロックチェーンの確認（チャネル閉鎖の有無の確認）から始めるため、起動してしまえば不正が行われたチャネルが存在するかはわかるためです。

もちろんそれがサービス提供を行っているノードであれば、金銭を盗まれなくても提供しているサービスが中断されるなどの被害には遭ってしまいますし、これは防ぐために取れる根本的な対策はありません。アップデートしましょう。

オフラインからの復帰に自信がないノードは最初からあまりライトニングノードとして好ましい状態ではありませんが、ウォッチタワーを利用することでBTCを盗まれてしまう対策は取れるでしょう。ウォッチタワーとはチャネル情報に基づくブロックチェーンの監視とペナルティトランザクションの配信を行ってくれる第三者のことです。利用率は高くありませんが、多少の抑止力になっている側面はあるかもしれません。

ただし、ライトニングチャネルの不正な閉鎖による攻撃全般に言えることですが、チャネル相手側の残高が非常に少なくなった状態からの攻撃はペナルティで失う金額も非常に小さくなるというインセンティブ面での問題がある（没収が大した抑止力にならない）ので、ウォッチタワーを使っているかわからなくても試行する価値があると判断する攻撃者もいるかもしれません。ウォッチタワーを使っていれば被害には遭いませんが。

今回の公表タイミングは妥当か？

さて、先週の記事に照らすと「この内容の脆弱性の公表に1年かかったのは妥当か？」という疑問が起こっても不思議ではありません。実際にこれを問題視する声もありますし、ライトニングノード運用者はビットコインノードより注意深くセキュリティ関連の情報を追うべきという指摘は間違っていません。

ただ、脆弱性の原因があまりにも単純なため、先週の記事でも述べたように「脆弱性があった」という事実を述べただけでも簡単に発見されてしまうおそれがあり、その場合に一般ユーザーにとって不明な脆弱性を用いて攻撃が繰り返される可能性もあったことを考えると非常にセンシティブな問題だとわかります。

個人的には報告から4ヶ月後には修正を含むバージョンが公開されており、そこから8ヶ月も経過してやっと公表というのは（攻撃者が独自に発見してしまうリスクも含めて）確かに遅いのではないかという気持ちがあります。Bitcoin Coreならともかく、Lndならば3～6ヶ月ほどでアップデートを強く推奨と通知してもよかったのではないでしょうか。

そういう意味ではまだまだLNは牧歌的な時代にあり、それによって救われている部分もあるのかもしれません。