tejas-nagchandi/cve-2021-45046Replicando CVE-2021-45046
Verificou-se que a correção para resolver a CVE-2021-44228 no Apache Log4j 2.15.0 estava incompleta em certas configurações não padrão. Isso poderia permitir que invasores com controle sobre os dados de entrada do Thread Context Map (MDC), quando a configuração de logging usa um Pattern Layout não padrão com uma Context Lookup (por exemplo, $${ctx:loginId}) ou um padrão Thread Context Map (%X, %mdc ou %MDC), criassem dados de entrada maliciosos usando um padrão JNDI Lookup, resultando em um ataque de negação de serviço (DOS). O Log4j 2.15.0 faz uma tentativa de melhor esforço para restringir as pesquisas JNDI LDAP ao localhost por padrão. O Log4j 2.16.0 corrige esse problema removendo o suporte para padrões de pesquisa de mensagens e desativando a funcionalidade JNDI por padrão.
O Log4j introduziu o conceito do Mapped Diagnostic Context ou MDC.
O Log4j 2 continua com a ideia do MDC e do NDC, mas os funde em um único Thread Context. O Thread Context Map é o equivalente do MDC e o Thread Context Stack é o equivalente do NDC. Embora sejam frequentemente usados para outros fins além do diagnóstico de problemas, eles ainda são frequentemente chamados de MDC e NDC no Log4j 2, pois já são bem conhecidos por essas siglas.
A maioria dos sistemas do mundo real precisa lidar com vários clientes simultaneamente. Em uma implementação típica multithread de tal sistema, diferentes threads lidarão com diferentes clientes. O logging é especialmente adequado para rastrear e depurar aplicações distribuídas complexas. Uma abordagem comum para diferenciar a saída de logging de um cliente de outro é instanciar um novo logger separado para cada cliente. Isso promove a proliferação de loggers e aumenta a sobrecarga de gerenciamento de logging.
Uma técnica mais leve é marcar exclusivamente cada solicitação de log originada da mesma interação do cliente. Neil Harrison descreveu esse método no livro "Patterns for Logging Diagnostic Messages", em Pattern Languages of Program Design 3, editado por R. Martin, D. Riehle e F. Buschmann (Addison-Wesley, 1997). Assim como um peixe pode ser marcado e ter seu movimento rastreado, marcar eventos de log com uma tag comum ou conjunto de elementos de dados permite que o fluxo completo de uma transação ou solicitação seja rastreado. Chamamos isso de Fish Tagging.
O Log4j fornece dois mecanismos para realizar Fish Tagging: o Thread Context Map e o Thread Context Stack. O Thread Context Map permite que qualquer número de itens seja adicionado e identificado usando pares chave/valor. O Thread Context Stack permite que um ou mais itens sejam inseridos na Stack e depois identificados por sua ordem na Stack ou pelos próprios dados. Como os pares chave/valor são mais flexíveis, o Thread Context Map é recomendado quando itens de dados podem ser adicionados durante o processamento da solicitação ou quando há mais de um ou dois itens.
Para marcar exclusivamente cada solicitação usando o Thread Context Stack, o usuário insere informações contextuais na Stack.
