0
0
O 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 terça-feira.
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 a ela uma pontuação CVSS de 7,5.
“Apache Log4j2 versões 2.0-alpha1 a 2.16.0 não protegeu da recursão descontrolada de pesquisas autorreferenciais. Quando a configuração de log usa um Layout Padrão não padrão com uma Pesquisa de Contexto (por exemplo, $${ctx:loginId}), atacantes com controle sobre dados de entrada do Thread Context Map (MDC) podem criar dados de entrada maliciosos que contenham uma pesquisa recursiva, resultando em um StackOverflowError que encerrará o processo. Isso também é conhecido como ataque DOS (Denial of Service)”, explicou Apache.
Eles acrescentaram que a última edição foi descoberta por Hideki Okamoto, da Akamai Technologies, e por um pesquisador anônimo de vulnerabilidades.
As mitigações incluem aplicar o patch 2.17.0 e substituir Pesquisas de Contexto como ${ctx:loginId} ou $${ctx:loginId} por padrões de Mapa de Contexto de Thread (%X, %mdc ou %MDC) no PatternLayout na configuração de log. O Apache também sugeriu remover referências a Pesquisas de Contexto na configuração como ${ctx:loginId} ou $${ctx:loginId}, onde elas se originam de fontes externas à aplicação, como cabeçalhos HTTP ou entrada do usuário.
Eles observaram que apenas o arquivo JAR Log4j-core é afetado pelo CVE-2021-45105.
Na sexta-feira, pesquisadores de segurança on-line começaram a twittar sobre possíveis problemas com o 2.16.0, com alguns identificando a vulnerabilidade de negação de serviço.
A discussão sobre Log4j dominou a conversa durante toda a semana. A CISA divulgou vários avisos exigindo que agências civis federais nos EUA apliquem patches antes do Natal, enquanto várias grandes empresas de tecnologia como IBM, Cisco e VMware correram para lidar com 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 pondo 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 a Conti estão explorando maneiras de aproveitar a vulnerabilidade.
O Google divulgou um relatório de segurança na sexta-feira, onde os membros da Open Source Insights Team James Wetter e Nicky Ringland disseram que descobriram que 35.863 dos artefatos Java disponíveis da 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 impactada por essa vulnerabilidade, explicaram os dois.
“O impacto médio do ecossistema dos avisos que afetam a 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. Mas os dois observaram que será difícil resolver o problema por causa da profundidade com que o Log4j está incorporado em alguns produtos.
“A maioria dos artefatos que dependem do log4j o faz indiretamente. Quanto mais profunda a vulnerabilidade estiver em uma cadeia de dependências, mais etapas serã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 afetando 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 analisar todos os avisos críticos divulgados publicamente que afetam os pacotes Maven, 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 Log4j seja resolvido.
FONTE: ZDNET