Pourquoi mettre à niveau Maven vers la version 3.8.1

Écrit par

19 juillet 2021

0 minutes de lecture

Si vous travaillez dans l’écosystème Java et développez vos applications avec une ancienne version de Maven, cet article vous concerne.

Vérifiez votre version de Maven en saisissant mvn -version ! Si vous utilisez encore une ancienne version de Maven, comme la 3.6.3 ou une version antérieure, vous devez absolument passer à la version 3.8.1 pour des raisons de sécurité. Notez que Java 7 ou une version ultérieure est nécessaire pour exécuter Maven 3.8.1.

Heureusement, le rapport 2021 sur l’écosystème JVM montre que peu de personnes utilisent Java 6 ou une version antérieure. En revanche, Maven est très répandu : ne pas effectuer la mise à niveau peut donc entraîner de graves problèmes pour une grande partie de l’écosystème.

Le problème des dépôts HTTP dans les anciennes versions de Maven

Les versions de Maven antérieures à la 3.8.1 permettaient aux utilisateurs de se connecter à des dépôts personnalisés via HTTP. Jonathan Leitschuh a signalé ce problème, documenté sous la référence CVE-2021-26291. Dans les notes de version de Maven 3.8.1, Maven distingue trois problèmes distincts :

Une attaque de l’homme du milieu (attaque MITM) due à l’utilisation de dépôts personnalisés via HTTP
Le détournement de domaines lorsque des dépôts personnalisés utilisent des domaines abandonnés
Le détournement potentiel de téléchargements par redirection vers des dépôts personnalisés

L’ordre de téléchargement des dépôts est décrit sur la page consacrée à l’ordre des dépôts comme suit :

Paramètres effectifs :
1. Globaux (définis dans ${maven.home}/conf/settings.xml)
2. Utilisateur (définis dans ${user.home}/.m2/settings.xml)
POM de build local effectif :
1. pom.xml local (fichier pom.xml du projet)
2. POM parents, de manière récursive
3. Super POM
POM effectifs depuis le chemin de dépendances jusqu’à l’artefact

Cela signifie qu’après avoir examiné les fichiers de paramètres, Maven recherche les dépôts dans le fichier pom.xml. La recherche se termine dans le Super POM, où est définie l’adresse de Maven Central.

POM effectifs depuis le chemin de dépendances jusqu’à l’artefact

La troisième étape est un peu complexe, mais voici une explication :

Prenons l’exemple d’un fichier POM de projet contenant une dépendance (depA) et déclarant également un dépôt personnalisé (myRepo1).

Maven recherchera d’abord depA dans myRepo1 avant de consulter Maven Central, car il examine en premier le fichier pom.xml local.

Si depA dépend d’un autre élément (depB) et que depA utilise myRepo2 (comme ci-dessous), où depB sera-t-il téléchargé ?

Schéma montrant des fichiers pom.xml de projets Maven reliés par les dépendances depA et depB dans les dépôts myRepo1 et myRepo2.

Pour télécharger depB, Maven consulte d’abord myRepo1, car il figure dans le POM du projet (étape 2a de l’ordre des dépôts, fichier pom.xml local). Il remonte ensuite jusqu’au POM parent, puis jusqu’à Maven Central via le Super POM. Si le package depB n’est PAS disponible sur Maven Central, il le télécharge depuis myRepo2.

Il s’agit d’une fonctionnalité de Maven, qui s’applique lorsque le package n’est pas publié sur Maven Central. Toutefois, il se peut aussi que Maven Central soit indisponible pour d’autres raisons.

Ce n’est peut-être pas ce à quoi vous vous attendez et, surtout, les versions de Maven antérieures à la 3.8.1 autorisent les dépôts HTTP.

Certains fichiers POM sur Maven Central contiennent des références à des dépôts personnalisés via HTTP. Les fichiers POM sur Maven Central étant immuables, les développeurs peuvent facilement ignorer qu’ils se connectent à un dépôt externe via HTTP à cause d’une dépendance transitive, ce qui les expose à une possible attaque MITM.

HTTPS par défaut dans Maven 3.8.1

Pour atténuer les problèmes évoqués ci-dessus, Maven a décidé de bloquer par défaut les dépôts HTTP externes. Pour cela, un champ <blocked> est ajouté à la configuration du miroir, et le miroir suivant est ajouté aux paramètres globaux situés dans ${maven.home}/conf/settings.xml.

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

Ainsi, les nouvelles applications créées avec Maven ne se connecteront pas aux dépôts externes via HTTP, mais uniquement via HTTPS. En effet, HTTPS garantit que le client communique avec le serveur demandé, ce qui contribue fortement à empêcher les attaques MITM.

Notez que les connexions HTTP à localhost et aux dépôts de fichiers restent autorisées.

En 2019, Jonathan Leitschuh a publié un excellent article sur la sécurité informatique : « Vous voulez prendre le contrôle de l’écosystème Java ? Il vous suffit d’une attaque MITM ! ». Consultez-le pour en savoir plus.

Comment effectuer la mise à niveau

Tout d’abord, téléchargez Maven 3.8.1 ou une version ultérieure, puis reconstruisez votre application. Si votre fichier pom.xml définit un dépôt, veillez également à remplacer son URL par une URL HTTPS. Si l’une de vos dépendances définit un dépôt HTTP, une erreur s’affichera. Commencez par rechercher une version plus récente de cette bibliothèque qui utilise une URL HTTPS à la place de l’URL HTTP.

Certaines entreprises utilisent des dépôts internes, qui peuvent encore fonctionner en HTTP plutôt qu’en HTTPS. Cela interrompra votre processus de build avec Maven 3.8.1. La meilleure solution consiste à investir une fois pour toutes dans la migration de ces dépôts vers HTTPS. Vous pouvez également modifier le paramètre du miroir si nécessaire. Créez votre propre configuration de miroir dans ${user.home}/.m2/settings.xml ou modifiez le fichier global settings.xml.

Le développement logiciel fait appel à de nombreuses dépendances. Ne les considérez pas comme acquises : les dépendances transitives s’inscrivent dans une chaîne de confiance. Veillez à choisir le bon package et à mettre vos dépendances à niveau régulièrement. Il est tout aussi essentiel de mettre à jour les outils que nous utilisons afin d’éviter l’introduction de packages malveillants dans nos systèmes.

Pour en savoir plus sur la sécurité de Maven et de Java

Apprécié par les développeurs. Les équipes de sécurité lui font confiance.

Les outils Snyk, conçus pour les développeurs, offrent une sécurité intégrée et automatisée qui répond à vos exigences de gouvernance et de conformité.

Réserver une démonstration en direct Commencer gratuitement