Em 17 de dezembro, 2021 em seu blog, a equipe do Google Open Source Insights explicou toda a situação que observaram em relação à vulnerabilidade do Apache Log4j. Eles descreveram a vulnerabilidade generalizada e o progresso atual na correção do ecossistema JVM de código aberto. Além disso, a equipe compartilhou suas idéias sobre quanto tempo possivelmente levará para que essa vulnerabilidade seja corrigida em todo o ecossistema e onde se concentrar a seguir.
Em 9 de dezembro, o ecossistema de segurança da informação soube da existência da vulnerabilidade, que apresenta alto grau de severidade e impacto generalizado. Dezenas de milhares de pacotes de software (artefatos no ecossistema Java) e os projetos usam uma ferramenta de registro popular, log4j que acabou tendo as vulnerabilidades discutidas. Como os especialistas explicam, essas vulnerabilidades permitem a execução remota de código, explorando o recurso de pesquisas JNDI desconfiadas expostas pela biblioteca de registro log4j. Em muitas versões da biblioteca, o recurso explorado existia por padrão.
A vulnerabilidade do Apache Log4j vai demorar um pouco para ser corrigida
Não muito tempo atrás, as vulnerabilidades log4j divulgadas tocaram mais do que 35,000 Pacotes Java, numeração para mais 8% do repositório Maven Central. Com o repositório sendo o repositório de pacotes Java mais significativo, ele causou um amplo resultado para a indústria de software. Especialistas apontam que 8% é um grande resultado para o resultado do ecossistema, enquanto o número médio para o resultado dos conselhos do Maven Central vai com 2% e a mediana menor que 0.1%. Embora os números mencionados não incluam todos os pacotes Java, por exemplo binários distribuídos diretamente.
No momento da publicação da postagem, quase cinco mil dos artefatos em questão foram corrigidos. E acabou 30,000 artefatos, muitos dependem de outro artefato, ainda espero para ser corrigido. A equipe menciona que eles contaram um artefato como consertado se o artefato teve pelo menos uma versão impactada e lançou uma versão estável maior não impactada (que está de acordo com o versionamento semântico). No caso de log4j, um artefato é considerado fixo se tiver sido atualizado para 2.16.0 ou não tem mais dependência de log4j.
Dois problemas significativos atrapalham o processo de correção
Embora as situações em geral possam ser definidas como claras, os especialistas apontam dois problemas de correção significativos. O primeiro objetivo que eles definem é o fato de que muitos artefatos dependem indiretamente do log4j. Aqueles de dependências diretas são responsáveis por cerca de 7,000 dos artefatos afetados. Nesse caso, qualquer uma de suas versões depende de uma versão afetada de log4j-core ou log4j-api, descrito nos CVEs. A dependência indireta ou transitiva significa as dependências das próprias dependências.
Toda essa equipe de dependência cria obstáculos significativos para consertar se olharmos para isso com cadeias de dependências. Aqui tudo fica bem claro: Quanto mais profundo o vulnerabilidade cai, quanto mais passos se deve seguir para consertá-lo. De acordo com os gráficos de dependência dos consumidores da equipe, os resultados do histograma mostraram grandes números. Em mais de 80% da vulnerabilidade dos pacotes é mais de um nível de profundidade. Na maioria dos quais está cinco níveis abaixo e em cerca de nove níveis abaixo. O processo de correção exigirá ir primeiro para as dependências mais profundas e depois toda a árvore.
Intervalos abertos dão a oportunidade de selecionar a versão lançada mais recentemente
Outra dificuldade reside nas escolhas em nível de ecossistema no algoritmo de resolução de dependência e convenções de especificação de requisitos. A prática difere daquelas como npm, onde rotineiramente especificam intervalos abertos para requisitos de dependência. Intervalos abertos dão a oportunidade de selecionar a versão lançada mais recentemente que satisfaça os requisitos de dependência. E, subsequentemente, traz novas correções. Os usuários recebem uma versão corrigida na próxima compilação após a disponibilidade do patch. Ele gera as dependências mais rapidamente.
“No ecossistema Java, é uma prática comum especificar os requisitos de versão “soft” - versões exatas que são usadas pelo algoritmo de resolução se nenhuma outra versão do mesmo pacote aparecer anteriormente no gráfico de dependência. A propagação de uma correção geralmente requer uma ação explícita dos mantenedores para atualizar os requisitos de dependência para uma versão corrigida,” Equipe de insights de código aberto escreveu neste segundo problema.
Com estes, a equipe aconselha a comunidade de código aberto a habilitar atualizações de dependências automatizadas e adicionar atenuações de segurança. Eles também forneceram uma lista de 500 pacotes afetados com alguns dos maiores usos transitivos. Na opinião dos especialistas, priorizar esses pacotes irá facilitar os esforços de consertar e, posteriormente, desbloquear mais da comunidade. A equipe agradeceu aos mantenedores e consumidores de código aberto que atualizaram suas versões do log4j.
Para a questão de quanto tempo levaria para consertar completamente tudo, a equipe expressou uma opinião vaga. Eles dizem que é difícil saber. Se todos os avisos críticos divulgados publicamente afetando os pacotes Maven, o processo pode demorar um pouco. Eles dizem que menos da metade (48%) dos artefatos afetados por uma vulnerabilidade foram corrigidos. Mas na frente do log4j as coisas parecem promissoras com cerca de 13% que foram consertados.
