Por que você deve atualizar para o Maven 3.8.1

Se você trabalha com o ecossistema Java e desenvolve aplicações usando uma versão antiga do Maven, esta mensagem é para você.

Confira sua versão do Maven digitando mvn -version! Se você ainda usa uma versão antiga do Maven, como a 3.6.3 ou anterior, precisa atualizar para a versão 3.8.1 por motivos de segurança. Atenção: para executar o Maven 3.8.1, é necessário ter o Java 7 ou superior.

Felizmente, descobrimos no relatório do ecossistema JVM de 2021 que poucas pessoas ainda usam Java 6 ou versões anteriores. Também vemos que muita gente usa Maven, então deixar de atualizá-lo pode causar problemas sérios para uma grande parte do ecossistema.

O problema dos repositórios HTTP nas versões antigas do Maven

As versões do Maven anteriores à 3.8.1 permitiam que usuários se conectassem a repositórios personalizados por HTTP. O problema foi relatado por Jonathan Leitschuh e documentado em CVE-2021-26291. Nas notas de lançamento do Maven 3.8.1, o Maven distinguiu três problemas diferentes:

• Um ataque man-in-the-middle (ataque MITM) devido ao uso de repositórios personalizados por HTTP

• Sequestro de domínio quando repositórios personalizados usam domínios abandonados

• Possível sequestro de downloads por meio de redirecionamentos para repositórios personalizados

A ordem de download dos repositórios é descrita na página sobre a ordem dos repositórios da seguinte forma:

1. Configurações efetivas:

   1. Global (definida em ${maven.home}/conf/settings.xml)

   2. Do usuário (definida em ${user.home}/.m2/settings.xml)

2. POM de build local efetivo:

   1. pom.xml local (arquivo pom.xml do projeto)

   2. POMs pai, recursivamente

   3. Super POM

3. POMs efetivos do caminho de dependências até o artefato

Isso significa que, depois de consultar os arquivos de configuração, o Maven procura os repositórios no pom.xml. Essa busca termina no Super POM, onde está definido o endereço do Maven Central.

POMs efetivos do caminho de dependências até o artefato

A terceira etapa é um pouco complicada, mas vou tentar explicá-la:

Vamos analisar um arquivo POM de projeto que tem uma dependência (depA) e também declara um repositório personalizado (myRepo1).

O Maven vai procurar primeiro a depA no myRepo1, antes de consultar o Maven Central, porque verifica primeiro o pom.xml local.

Se a depA tiver uma dependência (depB) e a depA tiver um myRepo2 (como abaixo), de onde a depB será baixada?

Para baixar a depB, o Maven vai consultar primeiro o myRepo1, pois ele está no POM do projeto (etapa 2a da ordem dos repositórios, pom.xml local). Em seguida, vai percorrer os POMs pai até chegar ao Maven Central, por meio do Super POM. Se o pacote depB NÃO estiver disponível no Maven Central, ele será baixado do myRepo2.

Esse é um recurso do Maven e é válido quando o pacote não está publicado no Maven Central. No entanto, também pode acontecer de o Maven Central estar indisponível por outros motivos.

Talvez isso não seja o que você espera e, mais importante, versões do Maven anteriores à 3.8.1 permitem o uso de repositórios HTTP.

Há arquivos POM no Maven Central que contêm referências a repositórios personalizados por HTTP. Como os arquivos POM no Maven Central são imutáveis, é possível que desenvolvedores nem saibam que estão se conectando a um repositório externo por HTTP, incluído por uma dependência transitiva. Isso pode torná-los alvos de ataques MITM.

HTTPS por padrão no Maven 3.8.1

Para reduzir os riscos dos problemas discutidos acima, o Maven decidiu bloquear repositórios HTTP externos por padrão. Isso é feito adicionando um campo <blocked> à configuração do espelho e incluindo o espelho a seguir na configuração global, localizada em ${maven.home}/conf/settings.xml.

1<mirror>
2      <id>maven-default-http-blocker</id>
3      <mirrorOf>external:http:*</mirrorOf>
4      <name>Pseudo repository to mirror external repositories initially using HTTP.</name>
5      <url>https://0.0.0.0/</url>
6      <blocked>true</blocked>
7</mirror>

Como resultado, aplicações novas desenvolvidas com o Maven não se conectarão a repositórios externos por HTTP, apenas por HTTPS. Isso porque o HTTPS garante que o cliente está se comunicando com o servidor solicitado, o que impede ataques MITM em grande medida.

As conexões HTTP com localhost e repositórios de arquivos ainda são permitidas.

Em 2019, Jonathan Leitschuh escreveu um excelente artigo sobre segurança da informação, “Quer assumir o controle do ecossistema Java? Tudo o que você precisa é de um MITM!”, se quiser saber mais.

Como atualizar

Primeiro, baixe o Maven 3.8.1 ou superior e reconstrua sua aplicação. Além disso, se você tiver um repositório definido no arquivo pom.xml, atualize-o para usar uma URL HTTPS. Se um repositório HTTP estiver definido em uma das suas dependências, você receberá um erro. Primeiro, procure versões mais recentes dessa biblioteca que tenham substituído a URL do repositório HTTP por uma versão HTTPS.

Em alguns casos, as empresas usam repositórios internos. Eles ainda podem usar HTTP em vez de HTTPS, o que interromperá o processo de build com o Maven 3.8.1. A melhor solução é fazer esse investimento uma única vez e garantir que esses repositórios usem HTTPS. Como alternativa, basta alterar a configuração do espelho, se necessário. Você pode criar sua própria configuração de espelho em ${user.home}/.m2/settings.xml ou alterar o settings.xml global.

Usamos muitas dependências ao desenvolver software. Não devemos considerá-las garantidas, pois, ao lidar com dependências transitivas, tudo faz parte de uma cadeia de confiança. Escolha o pacote certo e atualize suas dependências regularmente. Da mesma forma, é essencial atualizar as ferramentas que usamos para evitar a entrada de pacotes maliciosos no nosso sistema.

Saiba mais sobre segurança no Maven e no Java

• Plugin Snyk para Maven: análise integrada de vulnerabilidades para desenvolvedores

• Como corrigir vulnerabilidades em projetos Maven

• 10 boas práticas de segurança em Java

• Como corrigir problemas de segurança em Java durante a programação no IntelliJ IDEA

• 10 boas práticas para criar um contêiner Java com Docker