Na biblioteca Log4j 2 foi identificada mais uma vulnerabilidade (CVE-2021-45105), que, diferentemente dos dois problemas anteriores, foi classificada como perigosa, mas não crítica. O novo problema permite causar uma interrupção no serviço e se manifesta como um loop infinito e falhas ao processar determinadas strings. A vulnerabilidade foi corrigida na versão do Log4j 2.17 lançada há algumas horas. O risco da vulnerabilidade é reduzido pelo fato de que o problema ocorre apenas em sistemas com Java 8.
Sistemas vulneráveis são aqueles que utilizam consultas de contexto (Context Lookup) para determinar o formato de saída dos logs, como ${ctx:var}. Nas versões do Log4j, a partir da 2.0-alpha1 até a 2.16.0, não havia proteção contra recursão incontrolada, permitindo que um atacante, por meio de manipulações no valor usado para a substituição, causasse um loop infinito, levando à exaustão da pilha e à falha do processo. Em particular, o problema ocorria ao substituir valores como "${${::-${::-$${::-j}}}}".
Além disso, pesquisadores da Blumira sugeriram uma variante de ataque a aplicativos Java vulneráveis que não aceitam requisições de rede externas; por exemplo, sistemas de desenvolvedores ou usuários de aplicativos Java podem ser atacados dessa forma. A essência do método é que, com processos Java vulneráveis no sistema do usuário que aceitam conexões de rede apenas do host local (localhost) ou que processam requisições RMI (Remote Method Invocation, porta 1099), um ataque pode ser realizado com código JavaScript executado ao abrir uma página maliciosa no navegador dos usuários. Para estabelecer a conexão com a porta de rede do aplicativo Java durante um ataque desse tipo, utiliza-se a API WebSocket, que, ao contrário das requisições HTTP, não aplica as restrições de same-origin (WebSocket também pode ser utilizado para escanear portas de rede no host local, a fim de identificar manipuladores de rede disponíveis).
Também é interessante notar os resultados da avaliação de vulnerabilidades de bibliotecas publicadas pela Google, relacionadas às dependências do Log4j. De acordo com a Google, o problema afeta 8% de todos os pacotes no repositório Maven Central. Em particular, 35863 pacotes Java estavam vulneráveis devido a dependências diretas e indiretas do Log4j. Sendo assim, o Log4j é utilizado como dependência direta de primeiro nível apenas em 17% dos casos, enquanto em 83% dos pacotes afetados pela vulnerabilidade a ligação é feita através de pacotes intermediários dependentes do Log4j, ou seja, dependências de segundo nível ou superiores (21% - segundo nível, 12% - terceiro, 14% - quarto, 26% - quinto, 6% - sexto). A taxa de correção da vulnerabilidade deixa a desejar, pois uma semana após a descoberta da vulnerabilidade, dos 35863 pacotes identificados, o problema foi resolvido apenas em 4620, ou seja, 13%.
Enquanto isso, a Agência de Cibersegurança e Proteção de Infraestrutura dos EUA publicou uma diretiva de emergência, exigindo que as agências federais identifiquem os sistemas de informação vulneráveis ao Log4j e, até 23 de dezembro, instalem atualizações que bloqueiem o problema. Até 28 de dezembro, as organizações devem relatar as atividades realizadas. Para facilitar a identificação dos sistemas problemáticos, foi preparado uma lista de produtos em que a vulnerabilidade foi confirmada (a lista contém mais de 23 mil aplicativos).
Fonte: opennet.ru
