Em 17 de dezembro, 2021 em seu blog, a equipe do Google Open Source Insights explicou toda a situação observada 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. A equipe também compartilhou suas idéias sobre quanto tempo levará para que essa vulnerabilidade seja corrigida em todo o ecossistema e onde focar em seguida.
No dia 9 de dezembro o ecossistema de segurança da informação tomou conhecimento da existência da vulnerabilidade que apresenta grande grau de gravidade e impacto generalizado. Dezenas de milhares de pacotes de software (artefatos no ecossistema Java) e 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 pesquisa JNDI tímido revelado pela biblioteca de registro log4j. Em muitas versões da biblioteca, o recurso explorado existia por padrão.
A vulnerabilidade do Apache Log4j demorará um pouco para ser corrigida
Há pouco tempo, as vulnerabilidades do log4j divulgadas afetaram mais de 35,000 Pacotes Java, numeração acima 8% do repositório Maven Central. Sendo o repositório o repositório de pacotes Java mais significativo, ele causou um amplo resultado para a indústria de software. Especialistas apontam que 8% é um resultado enorme para o resultado do ecossistema, enquanto o número médio para o resultado dos avisos 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 do post, quase cinco mil dos artefatos em questão foram consertados. E acabou 30,000 artefatos, muitos dependentes de outro artefato, ainda espere para ser corrigido. A equipe menciona que contaria um artefato como corrigido se o artefato tivesse pelo menos uma versão impactada e tivesse lançado uma versão estável maior e não impactada (isso está de acordo com o versionamento semântico). No caso do log4j um artefato é considerado corrigido se tiver sido atualizado para 2.16.0 ou não depende mais do log4j.
Dois problemas significativos dificultam o processo de correção
Embora as situações em geral possam ser definidas como claras, os especialistas apontam dois problemas significativos de fixação. O primeiro objetivo que eles definem é o fato de que muitos artefatos dependem indiretamente do log4j. Os de dependências diretas representam 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 dependência transitiva significa as dependências das próprias dependências.
Toda essa equipe de dependência cria obstáculos significativos na correção se olharmos para isso com cadeias de dependência. Aqui tudo fica bem claro: Quanto mais profundo vulnerabilidade cai, mais etapas devem ser seguidas para corrigi-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 tem mais de um nível de profundidade. Na maioria dos quais está cinco níveis abaixo e em alguns níveis abaixo. O processo de correção exigirá ir primeiro às dependências mais profundas e depois a toda a árvore.
As gamas abertas 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ências e nas convenções de especificação de requisitos. A prática difere daquelas como npm, onde eles especificam rotineiramente intervalos abertos para requisitos de dependência. Os intervalos abertos dão a oportunidade de selecionar a versão lançada mais recentemente que satisfaça os requisitos de dependência. E posteriormente 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 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 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 sobre este segundo problema.
Com isso, a equipe aconselha a comunidade de código aberto a permitir atualizações automatizadas de dependências e adicionar mitigaçõ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 facilitará os esforços de correção e, posteriormente, desbloqueará mais a 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 tudo completamente, a equipe expressou uma opinião vaga. Eles dizem que é difícil saber. Se todos os avisos críticos divulgados publicamente que afetam os pacotes Maven, o processo poderá demorar um pouco. Eles dizem menos da metade (48%) dos artefatos afetados por uma vulnerabilidade foram corrigidos. Mas no front log4j as coisas parecem promissoras com cerca de 13% que foram corrigidos.
