Apache Log4jの脆弱性(CVE-2021-44228)問題の周囲で起きた話題について

本題については執筆時点でも刻々と状況が変わっておりますので本稿では触れませんが、その過程で起きた事象をいくつかピックアップしたいと思います。

脆弱性を利用したワクチンプログラムについて

本脆弱性がlog4jを通して「あまりにも何でもできてしまいすぎる」ことから問題発覚初期において「脆弱性を利用した脆弱性修正プログラム」なるものが本脆弱性の通称「Log4Shell」をもじった「Logout4Shell」としてリリースされました。
※あくまで自己責任ですので利用は推奨はされません。

筆者が数年前にセキュリティ製品の関連チームにいた頃、当時のマネージャと「脆弱性を修正する（脆弱性を利用した）トロイの木馬プログラムがあれば、勝手に修正を拡散してくれるから楽なんだけどなあ……」という話をしたことがあり、当時は「（倫理的に）ダメでしょ……」と苦笑したことを思い出しました。
当時与太話と笑った内容が、拡散性こそ持たないものの「脆弱性除去ワクチンウィルス」のような形で実現してしまったことに、今回の問題の大きさや当時は一蹴したアイディアをリリースできたという時代の変化に驚きを隠せずにいます。

再現情報の共有はどこまで許されるのか

また、もう一点直接関連しないながら「事象を再現するための情報共有はどこまでが許されるのか」という議論が再燃する事になっているようです。

これは特にOSS全般に言えることですが、脆弱性をコミュニティに報告する際や弊社含めサポートサービスに対する「どういった場合にこの問題が起きるのか？」といったお問い合わせに対し「こういった手法で脆弱性を利用される場合が考えられます」といった文書を提示することがあると思います。
この文書や図解が攻撃者に利用されてしまった場合に、コミュニティや顧客に情報を提供した側もそれを幇助したとみなされて「不正指令電磁的記録に関する罪」に問われてしまうのではないかといったことが論点となっています。

OSSではその特性上オープンなコミュニティでバグ報告を行うことがありますが、今回のようにあまりにも影響が大きな問題では、場合によっては報告者が責任を問われるといった想定がされるのも無理はないと思われます。
しかしながら、コミュニティの場を委縮させてしまったり、クローズドな場でのみ不具合報告を取り扱うようになってしまうようではクローズドな商用製品と同じようになってしまい、知見あるユーザの声を幅広く取り入れるといったOSSたる強みを失ってしまいます。そうならないよう願うばかりです。

現状では白黒のつかない扱いが難しい問題ではありますが、弊社サポートサービスにおいてもそういった情報についての取り扱いを一層注意するとし、今後の法整備なども踏まえ弊社でも状況を注視していきたいと思います。

※本記事は弊社保守サポートサービスに加入された方向けの情報配信メルマガ「OSSサポートサービスメールマガジン」から転記しております。

お問い合わせ

弊社では様々なサービスを取り扱っております。
詳細はサービス一覧からご覧ください。