Apache lança novo patch 2.17.0 para Log4j para resolver vulnerabilidade de negação de serviço

21/12/2021 mindsecblog Notícias 4

Apache lança novo patch 2.17.0 para Log4j para resolver vulnerabilidade de negação de serviço. A Apache Software Foundation publicou um novo patch Log4j na noite de sexta-feira após descobrir problemas com o 2.16.

Apache lançou a versão 2.17.0 do patch para Log4j depois de descobrir problemas com sua versão anterior, que saiu na semana passada.

O Apache disse que a versão 2.16 “nem sempre protege da recursão infinita na avaliação de pesquisa” e explicou que é vulnerável ao CVE-2021-45105 , uma vulnerabilidade de negação de serviço. Eles disseram que a gravidade é “alta” e deram uma pontuação CVSS de 7,5.

“O Apache Log4j2 versões 2.0-alpha1 a 2.16.0 não protegeu contra recursão não controlada de pesquisas autorreferenciais. Quando a configuração de registro usa um layout de padrão não padrão com pesquisa de contexto (por exemplo, $$ {ctx: loginId}) , os invasores com controle sobre os dados de entrada do Thread Context Map (MDC) podem criar dados de entrada maliciosos que contêm uma pesquisa recursiva, resultando em um StackOverflowError que encerrará o processo. Isso também é conhecido como ataque DOS (Denial of Service),” explicou a Apache.

Eles acrescentaram que o último problema foi descoberto por Hideki Okamoto da Akamai Technologies e um pesquisador de vulnerabilidade anônimo.

As atenuações incluem a aplicação do patch 2.17.0 e a substituição de pesquisas de contexto como $ {ctx: loginId} ou $$ {ctx: loginId} por padrões de mapa de contexto de thread (% X,% mdc ou% MDC) em PatternLayout na configuração de registro. O Apache também sugeriu remover referências a Pesquisas de Contexto na configuração como $ {ctx: loginId} ou $$ {ctx: loginId} onde se originam de fontes externas ao aplicativo, como cabeçalhos HTTP ou entrada do usuário.

Eles observaram que apenas o arquivo JAR do núcleo Log4j é afetado pelo CVE-2021-45105.

Na sexta-feira, pesquisadores de segurança online começaram a tweetar sobre possíveis problemas com o 2.16.0, com alguns identificando a vulnerabilidade de negação de serviço .

A discussão sobre o Log4j dominou as conversas durante toda a semana. A CISA lançou vários avisos exigindo que agências civis federais nos EUA aplicassem patches antes do Natal, enquanto várias grandes empresas de tecnologia como IBM, Cisco e VMware correram para resolver as vulnerabilidades Log4j em seus produtos.

A empresa de segurança Blumira afirma ter encontrado um novo vetor de ataque Log4j que pode ser explorado através do caminho de um servidor de escuta em uma máquina ou rede local, potencialmente colocando um fim à suposição de que o problema estava limitado a servidores vulneráveis expostos.

Outras empresas de segurança cibernética descobriram que grandes grupos de ransomware como o Conti estão explorando maneiras de tirar proveito da vulnerabilidade.

O Google divulgou um relatório de segurança na sexta-feira, onde os membros do Open Source Insights Team James Wetter e Nicky Ringland disseram que descobriram que 35.863 dos artefatos Java disponíveis no Maven Central dependem do código Log4j afetado. Isso significa que mais de 8% de todos os pacotes no Maven Central têm pelo menos uma versão que é afetada por esta vulnerabilidade, explicaram os dois.

“O impacto médio no ecossistema dos alertas que afetam o Maven Central é de 2%, com a mediana inferior a 0,1%“, disseram Wetter e Ringland.

Até agora, quase 5.000 artefatos foram corrigidos, deixando mais de 30.000 a mais. Mas os dois observaram que será difícil resolver o problema devido à profundidade do Log4j incorporado em alguns produtos.

“A maioria dos artefatos que dependem do log4j o faz indiretamente. Quanto mais profunda a vulnerabilidade em uma cadeia de dependências, mais etapas são necessárias para que ela seja corrigida. Para mais de 80% dos pacotes, a vulnerabilidade tem mais de um nível de profundidade, com a maioria afetada cinco níveis abaixo (e alguns até nove níveis abaixo) “, escreveram Wetter e Ringland.

“ Esses pacotes exigirão correções em todas as partes da árvore, começando pelas dependências mais profundas primeiro.“

Os dois continuaram dizendo que depois de olhar todos os avisos críticos divulgados publicamente que afetam os pacotes Maven, eles descobriram que menos da metade (48%) dos artefatos afetados por uma vulnerabilidade foram corrigidos, o que significa que pode levar anos para que o problema do Log4j seja resolvido.