Apache Log4j 2.15.0 における CVE-2021-44228 を修正するための対策が、特定の非デフォルト構成では不完全であることが判明しました。ロギング構成が非デフォルトの Pattern Layout を、Context Lookup（例: $${ctx:loginId}）または Thread Context Map パターン（%X、%mdc、%MDC）のいずれかとともに使用している場合、Thread Context Map（MDC）入力データを制御できる攻撃者は、JNDI Lookup パターンを使用して悪意のある入力データを作成し、サービス拒否（DOS）攻撃を引き起こす可能性があります。Log4j 2.15.0 は、デフォルトで JNDI LDAP ルックアップを localhost に制限するよう最善を尽くします。Log4j 2.16.0 は、メッセージルックアップパターンのサポートを削除し、JNDI 機能をデフォルトで無効にすることで、この問題を修正しています。
Log4j は、Mapped Diagnostic Context（MDC）の概念を導入しました。
Log4j 2 は MDC と NDC の考え方を引き継ぎながら、それらを単一の Thread Context に統合しています。Thread Context Map は MDC に相当し、Thread Context Stack は NDC に相当します。これらは問題の診断以外の目的で使用されることもよくありますが、Log4j 2 ではその頭字語がすでによく知られているため、今でも MDC および NDC と呼ばれることがよくあります。
ほとんどの実世界のシステムは、複数のクライアントを同時に処理する必要があります。そのようなシステムの典型的なマルチスレッド実装では、異なるスレッドが異なるクライアントを処理します。ロギングは、複雑な分散アプリケーションのトレースとデバッグに特に適しています。あるクライアントのログ出力を別のクライアントのものと区別する一般的な方法は、クライアントごとに新しい個別のロガーをインスタンス化することです。これによりロガーが増殖し、ロギングの管理オーバーヘッドが増加します。
より軽量な手法は、同じクライアントとの対話から開始された各ログリクエストに一意のスタンプを付けることです。Neil Harrison は、この方法を、R. Martin、D. Riehle、F. Buschmann 編の "Pattern Languages of Program Design 3" に収録された "Patterns for Logging Diagnostic Messages"（Addison-Wesley、1997 年）の中で説明しています。魚にタグを付けてその動きを追跡できるのと同様に、ログイベントに共通のタグまたは一連のデータ要素をスタンプすることで、トランザクションやリクエストの完全な流れを追跡できます。これを Fish Tagging と呼びます。
Log4j は、Fish Tagging を実行するための 2 つのメカニズムを提供します。Thread Context Map と Thread Context Stack です。Thread Context Map は、任意の数の項目を追加でき、キーと値のペアを使用して識別できます。Thread Context Stack は、1 つ以上の項目をスタックにプッシュし、スタック内の順序またはデータ自体によって識別できます。キーと値のペアの方が柔軟性が高いため、リクエストの処理中にデータ項目が追加される可能性がある場合や、項目が 1 つまたは 2 つを超える場合は、Thread Context Map が推奨されます。
Thread Context Stack を使用して各リクエストに一意のスタンプを付けるには、ユーザーはコンテキスト情報をスタックにプッシュします。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 https://logging.apache.org/log4j/2.x/manual/thread-context.html
