Apache Log4j の脆弱性について
Java環境で広く使われているオープンソースのログ出力ライブラリ"Log4j"に脆弱性が発見されたというニュースが配信されています。Apache Log4j は、Apache Software Foundation がオープンソースで提供している Javaベースのロギングライブラリであり、多くのJavaプロダクトで使われています。
本脆弱性についてお問い合わせをいただくことが多いため、弊社製品への影響について見解を表明いたします。
12月21日追加：環境変数設定による暫定対応になお脆弱性が残るのでは？との懸念について、末尾に追記しました。
リスクの評価
FileBlogのWebアプリケーションサーバは、この"Log4j"を使用していないため本件脆弱性にかかわる攻撃を直接受ける可能性はありません。少なくともFileBlogにログインできないユーザは、攻撃の手段を一切持たないため、まずは一安心とお考えください。
FileBlogのバックエンドで動作する全文検索エンジン Apache Solrが"log4j"を使用しているため、間接的に脆弱性をつかれるリスクがありますが、FileBlogのWeb画面からSolrに受け渡される検索キーワード文字列は、いったんFileBlogサーバによって解釈されてから再構成されてSolrに渡されています。結果、通常はマクロが無効化されるため本件脆弱性の影響を受けることはありません。
それでも、例外ケースとしてFileBlogのWebサーバのチェックをかいくぐりつつ脆弱性をつく方法が絶対にないとの確証は得られていません。
システムにログイン可能なユーザ（社員や協力会社ユーザなど）の中に悪意を持つユーザがいる場合に備えて、念のため対策をとることをおすすめします。
対策済バージョンのインストール
2021/12/24 Log4jライブラリを脆弱性修正版（2.17.0）にアップデートした FileBlog 4.4.0.45 をリリースしました。
リリース情報
最新版ダウンロード
Ver.4.4.0.45以降の環境へのバージョンアップによって自動的に対策済みとなります。
念のための対策（旧バージョン）
カスタマイズを加えている環境や、（Ver.3.xからのメジャーバージョンアップが必要な場合など）バージョンアップ作業に十分な時間を割けない環境では、下記の対応で旧バージョンのFileBlogに対しても本件脆弱性への対策を施すことができます。
システム環境変数を編集します
- コントロールパネル > システムとセキュリティ > システム > システム詳細設定 を開く
- システム環境変数 LOG4J_FORMAT_MSG_NO_LOOKUPS=true に設定する
- 環境変数の編集後、FbSolrサービスを再起動する
- SolrCloud環境の場合は、（Solrを停止してから）Zookeeperサービスを再起動する
以上で対策完了です。
念のための対策についての追記（2021年12月21日）
Apacheソフトウェア財団より、
「システム環境変数LOG4J_FORMAT_MSG_NO_LOOKUPS=true とする」対策には
一部のケースで不備があるということがアナウンスされました。
https://logging.apache.org/log4j/2.x/security.html
弊社は本アナウンスの内容について確認したところ、やはりFileBlogから使う分には影響がないという結論です。
念のため、FileBlogの次回リリース（Ver.4.4のマイナーリリース）を2022年1月中を目途に実施し、脆弱性対策済みの Log4j に置き換えたバージョンとする予定です。なお、Ver.3.x系での対応は計画になく暫定対応にて完了とさせていただきます。
LOG4J_FORMAT_MSG_NO_LOOKUPS=true でのリスク評価（参考）
今回判明したのは、ログ出力フォーマットにおいて、コンテキスト参照する箇所で外部からのHTTPリクエストなどで任意の文字列が受け渡される可能性があり、そこで任意のコードが実行されるリスクがあるというものでした。
FileBlogに組み込まれた Solr と ZooKeeper という二つのモジュールが Log4j を使う際のログフォーマットの設定は次のとおり定義されています。
Solr
C:\Program Files\Teppi Technology\FileBlog\4.0\Jetty\resources\log4j2.xml
Zookeeper
C:\Program Files\Teppi Technology\FileBlog\4.0\Zookeeper\conf\log4j.properties
その設定内容は次のとおりです。
Solr
%d{yyyy-MM-dd HH:mm:ss.SSS} %-5p (%t) [%X{collection} %X{shard} %X{replica} %X{core}] %c{1.} %m%n
Zookeeper
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
log4j.appender.ROLLINGFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
log4j.appender.TRACEFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L][%x] - %m%n
ここで使われる %d はタイムスタンプ、%p はログレベル、%t はスレッド名、%C{1} はクラス名、％L はソースの行番号、%m はメッセージ、%n は改行コードで、任意の文字列が混入する余地はありません。
特に注意が必要とされるコンテキスト参照箇所は
solrでは、%X{collection}、%X{shard}、%X{replica}、%X{core}の４つであり、これらは全てFileBlogシステム内で生成される定数の値（ドキュメントルートに対応する検索コレクションの名称など）です。
zookeeperでは、%X{myid}には1サーバにつき1つのサーバID（整数値）が与えられます。 複数の検索インデックスを協調動作させるケースでSolrCloudを構成するノード同士の通信を受け持つ内部モジュールであり、Solrインスタンス以外の外部からのリクエストを受け付けるものではなく任意文字列を渡すことはできません。
以上のことから現時点でFileBlogのバックエンドで動作する限りにおいて、Log4jの脆弱性についてリスクはないものと判断しております。
ただしSolrやzookeeperが一定の条件で、設定ファイルで指定されたものと別のログフォーマットでログを出力するケースがあるならば、そこにはリスクが潜みます。（オープンソースなのでソースコードをすべて精査すればそういう箇所がないことの確認ができますが、弊社ではそこまでの確認は行っておりません。しかし、あえてログフォーマットをハードコードするメリットは全くないので、その危険は極めて小さいでしょう）
