Javaのロギングライブラリ「Apache Log4j 2.x（以下、Log4j 2）」に発見されたリモートコード実行の脆弱性、通称「log4Shell」がIT業界を騒がせている。この脆弱性は、同ライブラリで提供されているJNDI Lookupと呼ばれる機能に起因するものだが、Log4j 2と並んで広く利用されているJavaロギングライブリの「Logback」もこれと似た機能を提供しており、Logbackの開発チームは安全のためにこの機能を無効にするアップデートをリリースした。ただし、Logbackの場合、攻撃に悪用するための前提条件が極めて厳しいため、Log4j 2とは違って悪用は困難と見られている。

Log4j 2における脆弱性については、次の記事を参考にしていただきたい。

Log4j 2における脆弱性の報告を受けて、Logback開発チームは12月14日にLogbackのバージョン1.2.8をリリースした。

  • 14th of December、2021、Release of version 1.2.8

    14th of December, 2021, Release of version 1.2.8

このリリースでは、JNDI Lookup機能に関する次の2つの修正が行われている。

・すべてのJNDI Lookupに関するコードを無効にした
・すべてのデータベース（JDBC）関連のコードを置き換えなしで削除した

ただし、前者に関しては「追って通知があるまで」という前提が付けられている。

LogbackはLog4j 2と異なり、JNDI Lookupの機能が直接提供されているわけでないが、DBAppenderと呼ばれるデータベースにログを書き込む機能において、データベースのデータソースをJNDI経由で取得できるようにすることによって攻撃に悪用できる可能性が存在するという。ただし、データソースは構成ファイルに直接書き込まれている情報であるため、攻撃に悪用するには次の前提条件を満たす必要がある。

・ 構成ファイルlogback.xmlへの書き込み権限を持っている
・ 修正された構成データのリロードが実行できる

これは、攻撃者が何らかの別の脆弱性を利用するなどしてシステムを侵害し、構成ファイルを任意に書き換えなければならないことを表している。この前提条件を満たした時点で、リモートコード実行とは無関係に、システムは極めて危険な状態に置かれている。

上記の観点から、LogbackにアップデートはLog4j 2のような緊急性のあるものではなく、影響を精査した上で任意のタイミングで行えば十分だと考えることができるだろう。追加の対策としては、ログバック構成ファイルを読み取り専用に設定しておくことが挙げられている。