Log4j 2.17.1 corrige a execução remota de código CVE-2021-44832 (mas não é tão grave quanto parece)

Como previsto anteriormente, por volta das 19h35 GMT de 28 de dezembro de 2021, outra vulnerabilidade de segurança que afeta a biblioteca de logs Log4j foi publicada como CVE-2021-44832.

Esta nova vulnerabilidade de segurança, CVE-2021-44832, afeta versões até a 2.17.0, que antes se acreditava estar corrigida. Essa vulnerabilidade é semelhante à CVE-2021-4104, que afetou a ramificação 1.x do Log4j.

O impacto da CVE-2021-44832

Se você puder atualizar rapidamente para a versão mais recente corrigida do Log4j, esse é o caminho recomendado. Ainda assim, vale destacar que esta vulnerabilidade específica, CVE-2021-44832, recebeu uma pontuação média de 6,6 no CVSS e exige que o invasor atenda a pré-condições consideravelmente mais restritivas para explorá-la com sucesso.

A CVE-2021-44832 classifica o Log4j 2.17.0 (e versões anteriores) como vulnerável à execução de código caso um invasor consiga controlar e modificar o conteúdo do arquivo de configuração de logs para apontar para uma fonte de dados URI remota e carregar código Java arbitrário.

A correção da versão 2.17.1, também disponibilizada em versões anteriores da biblioteca compatíveis com JVM, mitigou essa vulnerabilidade ao restringir a fonte de dados JNDI no arquivo de configuração, permitindo apenas o uso do protocolo Java e impedindo chamadas de rede remotas.

Ações imediatas para corrigir a CVE-2021-44832

A equipe do Log4j publicou correções para esta vulnerabilidade de segurança:

• Se você usa Java 8 ou posterior, atualize para o Log4j 2.17.1

• Se você usa a ramificação 2.12.x para Java 7, atualize para o Log4j 2.12.4

• Se você usa a ramificação 2.3.x para Java 6, atualize para o Log4j 2.3.2

Uma onda de vulnerabilidades do Log4j vazadas antes da hora

A divulgação desta vulnerabilidade segue uma tendência cada vez mais preocupante de divulgações irresponsáveis relacionadas ao Log4j: pesquisadores de segurança têm vazado detalhes das vulnerabilidades que encontraram antes que os mantenedores tenham tempo de corrigir o problema adequadamente e publicar novas versões.

Esse fenômeno problemático começou com a RCE original do Log4j, quando pesquisadores divulgaram detalhes e até uma prova de conceito da vulnerabilidade no Twitter e no GitHub horas antes da divulgação oficial (veja nossa linha do tempo). Mais uma vez, a existência desta vulnerabilidade foi vazada no Twitter várias horas antes do lançamento oficial, por um pesquisador de segurança que reivindicou o crédito pela descoberta.

Parece que, nos dois casos, o vazamento de informações, embora provavelmente não tenha sido mal-intencionado, levou a Apache a apressar o lançamento (o que poderia abrir espaço para outras vulnerabilidades e bugs na nova versão). Além disso, neste caso específico, podemos supor que, se pudesse escolher, a Apache não teria optado por apressar um lançamento em uma época do ano em que muitas organizações têm feriados prolongados e, por isso, teriam menos condições de avaliar e corrigir o problema rapidamente, se necessário.

A segurança do código aberto é cada vez mais importante para o mundo todo, e as práticas de divulgação responsável são fundamentais para a segurança contínua da nossa comunidade. Esperamos que futuras divulgações relacionadas ao Log4j ou a outros pacotes de código aberto possam ser conduzidas com mais segurança.

Como sempre, nós da Snyk seguimos comprometidos com nosso programa de divulgação responsável, mantendo a vigilância diante de possíveis novas ameaças e fornecendo informações rápidas e práticas aos nossos usuários e à comunidade de código aberto em geral.