Por qué deberías actualizar a Maven 3.8.1

Si trabajas en el ecosistema Java y desarrollas tus aplicaciones con una versión antigua de Maven, este mensaje es para ti.

Comprueba tu versión de Maven escribiendo mvn -version. Si todavía usas una versión antigua de Maven, como la 3.6.3 o una anterior, definitivamente debes actualizar a la versión 3.8.1 por motivos de seguridad. Ten en cuenta que necesitas Java 7 o una versión posterior para ejecutar Maven 3.8.1.

Por suerte, descubrimos en el informe del ecosistema JVM de 2021 que no muchas personas trabajan con Java 6 o versiones anteriores. Vemos que mucha gente usa Maven, así que no actualizarlo puede ocasionar problemas graves para una gran parte del ecosistema.

El problema con los repositorios HTTP en versiones antiguas de Maven

Las versiones de Maven anteriores a la 3.8.1 permitían a los usuarios conectarse a repositorios personalizados mediante HTTP. Jonathan Leitschuh informó sobre este problema y está documentado en CVE-2021-26291. En las notas de la versión de Maven 3.8.1, Maven distingue tres problemas diferentes:

• Un ataque de intermediario (ataque MITM) debido al uso de repositorios personalizados mediante HTTP

• Secuestro de dominios cuando los repositorios personalizados usan dominios abandonados

• Posible secuestro de descargas mediante redirecciones a repositorios personalizados

El orden de descarga de los repositorios se describe en la página sobre el orden de los repositorios de la siguiente manera:

1. Configuración efectiva:

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

   2. Del usuario (definida en ${user.home}/.m2/settings.xml)

2. POM efectivo de compilación local:

   1. pom.xml local (el archivo pom.xml del proyecto)

   2. POM principal, de forma recursiva

   3. Super POM

3. POM efectivos de la ruta de dependencias al artefacto

Esto significa que, después de revisar los archivos de configuración, Maven busca repositorios en el pom.xml. Esto termina en el Super POM, donde se define la ubicación de Maven Central.

POM efectivos de la ruta de dependencias al artefacto

El tercer paso es un poco complicado, pero intentaré explicarlo:

Veamos el archivo POM de un proyecto que tiene una dependencia (depA) y también declara un repositorio personalizado (myRepo1).

Maven primero buscará depA en myRepo1 antes de ir a Maven Central, porque primero revisa el pom.xml local.

Si depA tiene una dependencia (depB) y depA tiene un myRepo2 (como se muestra abajo), ¿desde dónde se descargará depB?

Para descargar depB, Maven primero revisará myRepo1 porque está en el POM del proyecto (paso 2a del orden de los repositorios, pom.xml local). Luego, recorrerá los POM principales hasta llegar a Maven Central a través del Super POM. Si el paquete depB NO está disponible en Maven Central, descargará el paquete desde myRepo2.

Esta es una función de Maven y es válida cuando el paquete no está publicado en Maven Central. Sin embargo, también puede ocurrir que Maven Central no esté disponible por otros motivos.

Quizá esto no sea lo que esperas y, lo que es más importante, Maven permite repositorios HTTP en las versiones anteriores a la 3.8.1.

Hay archivos POM en Maven Central que incluyen referencias a repositorios personalizados mediante HTTP. Los archivos POM de Maven Central son inmutables, por lo que es posible que los desarrolladores no sepan que se conectan a un repositorio externo mediante HTTP debido a una dependencia transitiva, lo que los convierte en posibles objetivos de un ataque MITM.

HTTPS de forma predeterminada en Maven 3.8.1

Para mitigar los problemas mencionados, Maven decidió bloquear los repositorios HTTP externos de forma predeterminada. Esto se logra agregando un campo <blocked> en la configuración del mirror y proporcionando el siguiente mirror en la configuración global ubicada en ${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>

El resultado es que las nuevas aplicaciones compiladas con Maven no se conectarán a repositorios externos mediante HTTP, sino únicamente mediante HTTPS. Esto se debe a que HTTPS garantiza que el cliente se comunique con el servidor solicitado. Esto previene en gran medida los ataques MITM.

Ten en cuenta que las conexiones HTTP a localhost y a los repositorios de archivos siguen permitidas.

En 2019, Jonathan Leitschuh escribió un excelente artículo de seguridad informática, “¿Quieres tomar el control del ecosistema Java? ¡Solo necesitas un MITM!”, si quieres obtener más información.

Cómo actualizar

Primero, descarga Maven 3.8.1 o una versión posterior y vuelve a compilar tu aplicación. Además, si tienes un repositorio definido en el archivo pom.xml, corrígelo para que use una URL HTTPS. Si una de tus dependencias define un repositorio HTTP, recibirás un error. Primero, busca versiones más recientes de esa biblioteca que hayan reemplazado la URL del repositorio HTTP por una versión HTTPS.

En algunos casos, las empresas usan repositorios internos. Estos pueden seguir usando HTTP en lugar de HTTPS, lo que interrumpirá el proceso de compilación con Maven 3.8.1. La mejor solución es hacer una inversión única y asegurarte de que estos repositorios usen HTTPS. Como alternativa, esta es simplemente una configuración de mirror que puedes cambiar si es necesario. Puedes crear tu propia configuración de mirror en ${user.home}/.m2/settings.xml o cambiar el archivo settings.xml global.

Usamos muchas dependencias al desarrollar software. No debemos darlo por sentado, ya que todo esto conforma una cadena de confianza cuando tenemos que trabajar con dependencias transitivas. Asegúrate de elegir el paquete correcto y actualizar tus dependencias a tiempo. También es esencial actualizar las herramientas que usamos para evitar que haya paquetes maliciosos en nuestro sistema.

Más información sobre Maven y la seguridad de Java

• Plugin de Snyk para Maven: análisis integrado de vulnerabilidades para desarrolladores

• Cómo corregir vulnerabilidades en proyectos de Maven

• 10 prácticas recomendadas de seguridad para Java

• Cómo corregir problemas de seguridad de Java mientras programas en IntelliJ IDEA

• 10 prácticas recomendadas para crear un contenedor de Java con Docker