Outra vulnerabilidade foi identificada na biblioteca Log4j 2 (CVE-2021-45105), que, diferentemente dos dois problemas anteriores, é classificada como perigosa, mas não crítica. O novo problema permite causar negação de serviço e se manifesta na forma de loops e travamentos ao processar determinadas linhas. A vulnerabilidade foi corrigida na versão Log4j 2.17 lançada há algumas horas. O perigo da vulnerabilidade é mitigado pelo fato do problema aparecer apenas em sistemas com Java 8.
A vulnerabilidade afeta sistemas que usam consultas contextuais (Context Lookup), como ${ctx:var}, para determinar o formato de saída do log. As versões Log4j de 2.0-alpha1 a 2.16.0 não tinham proteção contra recursão descontrolada, o que permitia que um invasor manipulasse o valor usado na substituição para causar um loop, levando ao esgotamento do espaço de pilha e a um travamento. Em particular, o problema ocorreu ao substituir valores como "${${::-${::-$${::-j}}}}".
Além disso, pode-se notar que pesquisadores da Blumira propuseram uma opção para atacar aplicações Java vulneráveis que não aceitam solicitações de rede externa; por exemplo, os sistemas de desenvolvedores ou usuários de aplicações Java podem ser atacados desta forma. A essência do método é que se houver processos Java vulneráveis no sistema do usuário que aceitam conexões de rede apenas do host local ou processam solicitações RMI (Invocação de Método Remoto, porta 1099), o ataque pode ser realizado por código JavaScript executado quando os usuários abrem uma página maliciosa em seus navegadores. Para estabelecer uma conexão com a porta de rede de um aplicativo Java durante tal ataque, é usada a API WebSocket, à qual, ao contrário das solicitações HTTP, não são aplicadas restrições de mesma origem (o WebSocket também pode ser usado para verificar portas de rede no local host para determinar os manipuladores de rede disponíveis).
Também são interessantes os resultados publicados pelo Google sobre a avaliação da vulnerabilidade de bibliotecas associadas às dependências do Log4j. Segundo o Google, o problema afeta 8% de todos os pacotes do repositório Maven Central. Em particular, 35863 pacotes Java associados ao Log4j através de dependências diretas e indiretas foram expostos a vulnerabilidades. Ao mesmo tempo, Log4j é usado como dependência direta de primeiro nível apenas em 17% dos casos, e em 83% dos pacotes afetados a ligação é realizada por meio de pacotes intermediários que dependem do Log4j, ou seja, vícios de segundo e superior nível (21% - segundo nível, 12% - terceiro, 14% - quarto, 26% - quinto, 6% - sexto). O ritmo de correção da vulnerabilidade ainda deixa muito a desejar; uma semana após a vulnerabilidade ter sido identificada, dos 35863 pacotes identificados, o problema foi corrigido até agora em apenas 4620, ou seja, em 13%.
Enquanto isso, a Agência de Segurança Cibernética e Proteção de Infraestrutura dos EUA emitiu uma diretiva de emergência exigindo que as agências federais identifiquem os sistemas de informação afetados pela vulnerabilidade Log4j e instalem atualizações que bloqueiem o problema até 23 de dezembro. Até 28 de dezembro, as organizações são obrigadas a apresentar relatórios sobre o seu trabalho. Para simplificar a identificação de sistemas problemáticos, foi preparada uma lista de produtos que comprovadamente apresentam vulnerabilidades (a lista inclui mais de 23 mil aplicações).
Fonte: opennet.ru