米IBMのSenior Business Architectで、情報発信を活発に行っているジェシー・ゴルジンスキー（Jesse Gorzinksi）氏が、「Log4Shellのセキュリティ脆弱性に関するFAQにお答えします」（Log4Shell Part 1: Answering FAQs on the Log4Shell Security Vulnerability）と題するブログを発表した。同氏の許可を得て、翻訳・掲載する。
text：ジェシー・ゴルジンスキー IBM
最近公表されたLog4j（別名：Log4Shell、LogJam）のセキュリティ脆弱性について、ご存じの方も多いと思います。この脆弱性を悪用するのは簡単で、攻撃者はリモートでコードを実行できます。これは絶対に無視できない問題です。
この問題の本質を理解していただくために、2つのシリーズ記事を用意しました。本稿はそのPart1として、よく寄せられる質問への回答を紹介します。
Q：この脆弱性に関する公式ドキュメントはどこにありますか？
この脆弱性には「CVE-2021-44228」というIDが割り当てられています。ほとんどのセキュリティ脆弱性と同様に、National Vulerability Database (NVD：編集部＊注1）に記録されています。NVDの公式ドキュメントは、こちらでご覧になれます。
＊1 NVDは米国政府が運営する脆弱性管理データベース
Q：Log4Shellの脆弱性は、どのOSに影響しますか？
これはJavaの脆弱性ですので、どのOS上で動作しているJavaアプリケーションにも影響します。特定のOS自体に影響があるわけではなく、その中で動作しているJavaプログラムに影響があるだけです。
Q：自社のJavaプログラムは、どのように問題を修正すればよいですか？
Log4jの脆弱性は、システム上で動作しているJavaアプリケーションを修正する必要があります。以下の手順に従ってください。
ステップ1：Log4JのLookup機能を無効にする
log4j 2.10以降のバージョンでは、Javaのシステムプロパティである「log4j2.formatMsgNoLookups」を「true」に設定することで、Log4JのLookup機能を無効にすることができます。または、LOG4J_FORMAT_MSG_NO_LOOKUPS環境変数を使用することもできます。IBM i上では、ADDENVVARで行うことができます。
ADDENVVAR ENVVAR(LOG4J_FORMAT_MSG_NO_LOOKUPS) VALUE(‘true’) REPLACE(*YES) LEVEL(*SYS)
また、この一時的な（そして不完全な）改善策を適用するための小さなシェルスクリプトも書きました（編集部＊注2）。
＊注2 Jesse Gorzinski氏はGitHub上の「ThePrez/IBMiOSS-utils」でIBM iのオープンソース関連の情報を公開している。上記のシェルスクリプトはこちらで公開されている。
上記の環境変数が設定されている場合、Log4jのバージョン2.10.0以降では、この脆弱性は発生しません。ご参考までに書き添えると、バージョン2.10は2017年11月に初リリースされました。楽観的に考えれば、それ以降にビルドまたはアップデートされたアプリケーションは2.10を実行するので、Lookup機能が無効化されていれば安全なはずです。
LOG4J_FORMAT_MSG_NO_LOOKUPS を設定することで混乱が生じる可能性は低く、あなたが他の改善策を探究する間、よい対応策になります。
ステップ 2: アプリケーションにおけるLog4jの使用状況を確認する
自社のアプリケーションがどのオープンソースソフトウェアを使用しているか、こまめに棚卸しを作成しているならば、それは素晴らしいことです。そうでない場合は、自社システムでLog4jのインスタンスを見つけるために最善の努力をすることです。
私の同僚、Scott Forstieは最近、IFS内でファイル名に「log4j」という文字列を持つすべてのファイルを見つけるためのSQLを発表しました（編集部＊注3）。あるいは、findutilsパッケージをインストールして、updatedbとlocateパッケージを活用することもできます。これは素晴らしいスタートですが、次のような注意点があります。
＊注3 Scott Forstie氏のGitHubへの投稿はこちら。
・たとえば、Log4jからSLF4Jへのアダプタは、「slf4j-log4j12-1.7.25.jar」という名前になる可能性があります。あなたが最も興味があるのは、「log4j-.jar」または「log4j-core-.jar」という形式のファイルでしょうから、注意が必要です。・また、updatedbやlocateの利用では、他の形式のアーカイブに組み込まれたLog4jのインスタンスを見つけ出すことができません。たとえば、WebアプリケーションがWebアーカイブ (.WAR) ファイルでデプロイされている場合は、Log4jを検出しません。ただし、より詳細な調査が必要なJavaプログラムを発見するために、目的のファイルタイプを探すようにクエリを変更することもできます。
最も包括的な分析としては、すべてのJavaプログラムとその依存関係を調査することが含まれます。しかし、「何が動いているのか、わからない！」と思っているかもしれません。しかし、システム上でどのようなワークロードが実行されていて、それらがどこにあるのかを知っておく必要があります。WRKJVMJOBも役に立ちます。それが一番よいスタート地点です 本番用ワークロードは、外部のハッカーにとって主要な攻撃経路となります。
ステップ3：Log4jのアップグレード
Log4jをバージョン2.16.0（またはそれ以降）にアップグレードすることは最良の選択です。Log4jはセマンティックバージョニングを使用しているため、他の2.xバージョンからのアップグレードは低リスクの操作となります。
Q：自社開発ではないJavaプログラムについては、どうしたらいいですか？
IBM製品への影響については、こちらのブログを参照してください。IBM製品およびサービスに関する最新情報を公開しています（こちら）。Javaを使用しているサードパーティ製品については、ソフトウェアベンダーにお問い合わせください。
Q：このセキュリティ脆弱性について心配する必要がありますか？
この種のセキュリティ脆弱性は大きな脅威です。アプリケーションの脆弱性が露出してしまうと、悪意のある存在に簡単に攻撃される恐れがあるからです。下記の状況があるかもしれないということを肝に銘じて、自社のセキュリティを評価してください。
・自社で使用しているアプリケーションは、脆弱性のあるLog4jのバージョンを実行しているのに違いない・攻撃者は、悪意のあるデータを自社アプリケーションに送り込めるに違いない。・自社アプリケーションは、悪意のあるサーバーへの新しいアウトバウンド通信を行えるに違いにない
付け加えれば、脆弱なバージョンのライブラリを使用していなければ、攻撃者に悪用される恐れはありません。たとえば、HTTPリクエストヘッダやチャットメッセージなどのログ取得のためにLog4jライブラリを使用しないのであれば、リスクは回避されます。
IBM iでは、多くのアプリケーションがバックエンドのJavaアプリケーションではなく、Apache HTTPサーバーを使用してHTTPリクエスト・データを記録しています。Apache HTTPサーバーはJavaで書かれていないので、ここでは公開されません。しかし、このような評価は難しいので、やはりソフトウェアスタックを分析し、Log4jのアップデートのようなパッチを最新にしておく必要があります。
Q：Log4jの脆弱性への対処から、何が学べるのでしょうか？
オープンソースソフトウェアは必要不可欠ですが、リスク評価、利用計画、緩和策など、適切な調査（デュー・ディリジェンス）が必要です。Log4jの脆弱性は、オープンソースソフトウェアを管理するためのいくつかの重要なベストプラクティスを強いるものです。Part 2では、あなたの組織のソフトウェアを安全に保ち、将来を保証するためのいくつかのテクニックについてお話します（i Magazineサイトでは、Part 2が公開され次第、紹介します）。
出典：Log4Shell Part 1: Answering FAQs on the Log4Shell Security Vulnerabilityhttps://techchannel.com/Trends/12/2021/log4shell-part-1
著者｜ジェシー・ゴルジンスキー（Jesse Gorzinksi）氏
IBMSenior Business Architect、Open Source Software on IBM i
ブログ：ibm.biz/open-your-i、Twitter：@IBMJesseG
IBMの経験豊富なビジネスアーキテクト。IBM iプラットフォームのスペシャリストにして、オープンソースの立役者。デジタルトランスフォーメーションに執着し、新しい技術を導入することに何の躊躇もしない！ という。伝説によると、1回のコーディングで完璧に動くプログラムを書いたというエピソードをもつ。犬の腹のマッサージ、マリオカート、そして米国の大西洋岸で最高のリエージュワッフルを作る達人でもある（LinkedInのプロフィール紹介より）
◎関連記事
・続報-3｜Db2（フェデレーション機能）、IBM COS、Cognos、QRadar、Guardiumなど多数 ～Log4j脆弱性の影響を受ける製品・サービスをIBMが発表・続報-2｜IBM MQ、Power HMC、IBM Sterling File Gatewayも ～Log4j脆弱性の影響を受ける製品をIBMが発表・続報-1｜SPSS、Netezza、NetcoolもLog4j脆弱性の影響を受ける ～IBMが最新情報を公開・Javaベースのログ出力ライブラリ「Log4j」に深刻な脆弱性 ～WebSphereやWatson Explorerも影響を受ける、クラウドサービスも調査中とIBM。各社も調査・対応中
［i Magazine・IS magazine］
