Warum Sie auf Maven Version 3.8.1 aktualisieren sollten

Wenn Sie im Java-Ökosystem arbeiten und Ihre Anwendungen mit einer älteren Maven-Version entwickeln, ist diese Nachricht an Sie gerichtet.

Prüfen Sie Ihre Maven-Version, indem Sie mvn -version eingeben! Wenn Sie noch eine ältere Maven-Version wie 3.6.3 oder niedriger verwenden, sollten Sie aus Sicherheitsgründen unbedingt auf Version 3.8.1 aktualisieren. Beachten Sie, dass für Maven 3.8.1 Java 7 oder höher erforderlich ist.

Glücklicherweise haben wir im JVM Ecosystem Report 2021 festgestellt, dass nur wenige mit Java 6 oder älter arbeiten. Da jedoch viele Maven verwenden, kann ein Verzicht auf das Upgrade für einen großen Teil des Ökosystems zu schwerwiegenden Problemen führen.

Das Problem mit HTTP-Repositories in älteren Maven-Versionen

Maven-Versionen vor 3.8.1 erlaubten es, über HTTP eine Verbindung zu benutzerdefinierten Repositories herzustellen. Darauf machte Jonathan Leitschuh aufmerksam; dokumentiert ist das Problem unter CVE-2021-26291. In den Versionshinweisen zu Maven 3.8.1 unterscheidet Maven drei separate Probleme:

• Ein Man-in-the-Middle-Angriff (MITM-Angriff) durch die Verwendung benutzerdefinierter Repositories über HTTP

• Domain-Hijacking, wenn benutzerdefinierte Repositories stillgelegte Domains verwenden

• Mögliches Hijacking von Downloads durch Weiterleitung an benutzerdefinierte Repositories

Die Reihenfolge beim Herunterladen aus Repositories wird auf der Seite zur Repository-Reihenfolge wie folgt beschrieben:

1. Effektive Einstellungen:

   1. Global (definiert in ${maven.home}/conf/settings.xml)

   2. Benutzer (definiert in ${user.home}/.m2/settings.xml)

2. Lokales effektives Build-POM:

   1. Lokales pom.xml (die Projektdatei pom.xml)

   2. Übergeordnete POMs rekursiv

   3. Super-POM

3. Effektive POMs entlang des Abhängigkeitspfads zum Artefakt

Das bedeutet: Nachdem Maven die Einstellungsdateien geprüft hat, sucht es in der pom.xml nach Repositories. Schließlich landet es bei der Super-POM, in der der Speicherort von Maven Central definiert ist.

Effektive POMs entlang des Abhängigkeitspfads zum Artefakt

Der dritte Schritt ist etwas knifflig, aber ich versuche, ihn zu erklären:

Sehen wir uns eine Projekt-POM-Datei an, die eine Abhängigkeit (depA) enthält und außerdem ein benutzerdefiniertes Repository (myRepo1) definiert.

Maven sucht zuerst in myRepo1 nach depA, bevor es Maven Central aufruft, da zunächst die lokale pom.xml geprüft wird.

Wenn depA eine Abhängigkeit (depB) hat und depA ein myRepo2 enthält (wie unten dargestellt), wo wird depB dann heruntergeladen?

Zum Herunterladen von depB sucht Maven zuerst in myRepo1, da dieses in der Projekt-POM steht (2a der Repository-Reihenfolge, lokale pom.xml). Anschließend geht Maven die übergeordneten POMs hinauf bis zu Maven Central über die Super-POM. Wenn das Paket depB NICHT in Maven Central verfügbar ist, wird es aus myRepo2 heruntergeladen.

Das ist ein Maven-Feature und für den Fall vorgesehen, dass das Paket nicht in Maven Central veröffentlicht wurde. Es kann jedoch auch andere Gründe dafür geben, dass Maven Central nicht verfügbar ist.

Das entspricht möglicherweise nicht Ihren Erwartungen. Noch wichtiger ist, dass Maven in Versionen vor 3.8.1 HTTP-Repositories zulässt.

Auf Maven Central gibt es POM-Dateien mit Verweisen auf benutzerdefinierte Repositories über HTTP. POM-Dateien auf Maven Central sind unveränderlich. Daher kann es leicht passieren, dass Entwickler nicht wissen, dass sie über eine transitive Abhängigkeit eine Verbindung zu einem externen Repository über HTTP herstellen. Dadurch können sie zum Ziel eines MITM-Angriffs werden.

HTTPS standardmäßig in Maven Version 3.8.1

Um die oben beschriebenen Probleme zu entschärfen, hat Maven beschlossen, externe HTTP-Repositories standardmäßig zu blockieren. Dazu wird der Spiegelkonfiguration ein Feld <blocked> hinzugefügt und der folgende Spiegel in den globalen Einstellungen unter ${maven.home}/conf/settings.xml eingetragen.

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>

Dadurch stellen neue Anwendungen, die mit Maven erstellt werden, keine Verbindung zu externen Repositories über HTTP, sondern nur über HTTPS her. HTTPS gewährleistet, dass der Client mit dem angeforderten Server kommuniziert. So werden MITM-Angriffe weitgehend verhindert.

Beachten Sie, dass HTTP-Verbindungen zu localhost und Datei-Repositories weiterhin zulässig sind.

Jonathan Leitschuh schrieb 2019 einen hervorragenden InfoSec-Artikel: „Want to take over the Java ecosystem? All you need is a MITM!“ Wenn Sie mehr erfahren möchten, lesen Sie ihn.

So führen Sie das Upgrade durch

Laden Sie zunächst Maven Version 3.8.1 oder höher herunter und erstellen Sie Ihre Anwendung neu. Wenn in Ihrer pom.xml-Datei ein Repository definiert ist, ändern Sie dessen URL in eine HTTPS-URL. Ist in einer Ihrer Abhängigkeiten ein HTTP-Repository definiert, erhalten Sie eine Fehlermeldung. Suchen Sie zunächst nach neueren Versionen der Bibliothek, in denen die HTTP-Repository-URL durch eine HTTPS-Version ersetzt wurde.

In manchen Fällen verwenden Unternehmen interne Repositories. Diese nutzen möglicherweise noch HTTP statt HTTPS, wodurch der Build-Prozess mit Maven Version 3.8.1 fehlschlägt. Am besten investieren Sie einmalig und stellen sicher, dass diese Repositories HTTPS verwenden. Alternativ können Sie diese Einstellung für Spiegel anpassen. Erstellen Sie eine eigene Spiegeleinstellung in Ihrer ${user.home}/.m2/settings.xml oder ändern Sie die globale Datei settings.xml.

Bei der Softwareentwicklung verwenden wir zahlreiche Abhängigkeiten. Das sollten wir nicht als selbstverständlich ansehen, denn bei transitiven Abhängigkeiten beruht alles auf einer Vertrauenskette. Achten Sie darauf, die richtigen Pakete auszuwählen und Ihre Abhängigkeiten rechtzeitig zu aktualisieren. Ebenso wichtig ist es, die verwendeten Tools zu aktualisieren, um schädliche Pakete in unseren Systemen zu verhindern.

Weitere Informationen zu Maven und Java-Sicherheit

• Snyk Maven plugin: Integriertes Scannen nach Sicherheitslücken für Entwickler

• Sicherheitslücken in Maven-Projekten beheben

• 10 Best Practices für Java-Sicherheit

• So beheben Sie Java-Sicherheitsprobleme beim Programmieren in IntelliJ IDEA

• 10 Best Practices zum Erstellen eines Java-Containers mit Docker