Apache Maven may follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository. Maven is changing the default behavior to no longer follow http (non-SSL) repository references by default in version 3.8.1
Details: Apache Maven uses pom files as descriptors to build software and declare dependencies. The pom files can contain references such as plugins and configuration to be used for compilation, testing, packaging etc, as well as a list of dependencies. Each dependency itself is also expected to contain basic information, including its own dependencies, allowing a transitive dependency tree to be calculated and resolved as needed. In cases where dependencies are not located in a default repository, a reference to an additional repository where the dependencies can be resolved may be included in the pom. There are two distinct use cases for how repositories defined in poms are used: When building a project that has a pom.xml file on disk that references a repository, the repository reference takes precedence over previous configuration. This is to be expected since in this mode, one should consider the declaration to be an explicit instruction as part of the build process. When building a project that depends upon a dependency which references a remote repository, things work differently. In this instance, the remote repository is added at the end of the search list and is scoped such that only dependencies of the pom referencing it may be retrieved from this referenced repository. This capability has existed in Maven since the beginning, because without the pointer to the location of these dependencies, a consumer’s build is going to fail. Since the repository was defined in the pom for use case #1 (ie at build time), it made sense to allow it to be automatically referenced during use case #2 (ie at dependency consume time). The order in which repositories are searched is documented at https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order. The issue at hand is that although users should always understand code they depend upon or reuse, many consumers of dependencies do not inspect the poms. Those users may not be aware that a pom can point their build at yet another repository to fetch dependencies and their poms. With this ability for 3rd party pom authors to point a build to a new location, it creates an opportunity for a malicious actor to direct builds to fetch dependencies from this untrusted repository. There is the additional possibility that a bad actor could take over an abandoned repository url. If the attackers are in a privileged location on the network, they could additionally exploit the lack of ssl encryption over legacy repository definitions and attempt a Man In The Middle (mitm) attack to insert malicious components. Given the fact that the average consumer of dependencies may not inspect poms for remote repositories and may not have other compensating mechanisms in place, the Maven project has decided to harden the default behavior in version 3.8.1 and above in the following ways: (MNG-7117): A new block parameter is added to the settings.xml mirror section. This allows a user to define a particular url that should never be accessed by setting block = true. (MNG-7116): A new external:http:* pattern is added to the mirrorOf field that allows a user to redirect or, in combination with the above block setting, block any repository reference that is not using ssl. In combination, with the existing negation patterns, this would allow users to selectively allow certain trusted repositories while blocking all others. See here for more information on these patterns: Maven – Guide to Mirror Settings Finally, (MNG-7118) we have added a new entry to the default conf/settings.xml which will automatically create a mirror of external:http:* with block set to true. This will have the effect of blocking all http repository references by default. Detailed release notes can be found at https://maven.apache.org/docs/3.8.1/release-notes.html While this hardening limits the impact of external repositories introduced by dependencies by only allowing ssl secured urls, and the scope of dependency resolution is limited such that these external repositories are searched a) last and b) only for dependencies in the pom where it was introduced, it does not completely eliminate all possible future attack vectors. For absolute control over the repositories used by Maven, the longstanding best practice for management of dependency resolution and allowed repositories has been to use a repository manager. The typical mechanism for enabling this mode of operation has Maven config set to override all repository definitions (for both use case 1 and 2) by means of setting “<mirrorOf>*</mirrorOf> in the Maven settings. This would cause Maven to make all external requests to your Repository Manager and thus only to the repositories defined and allowed in that system. If you are currently using a repository manager in this way, you are unaffected by the risks present in the legacy behavior, and are unaffected by this vulnerability and change to default behavior. See this link for more information about repository management: https://maven.apache.org/repository-management.html
