Zip Slip Vulnerability

As part of a broader research, the Snyk Security Research Team discovered an arbitrary file write generic vulnerability, that can be achieved using a specially crafted zip (or bzip2, gzip, tar, xz, war) archive, that holds path traversal filenames. So when the filename gets concatenated to the target extraction directory, if the extraction tool used does not make sufficient checks, the final path ends up outside of the target folder.

The Apache Maven team has been informed because the plexus-archiver library did not make sufficient checks and it is a library used by most of the packaging plugins. Affected versions of plexus-archiver are [,3.4]+[3.5], fixed versions are 3.4.1 & 3.6.0, with issue tracking plexus-archiver #87 and Snyk vulnerability report SNYK-JAVA-ORGCODEHAUSPLEXUS-31680

What parts of Maven are vulnerable?

Apache Maven itself is not vulnerable, since Maven doesn’t unpack by itself: unpacking actions are done by plugins.

Reading malicious archives in memory is also not an issue, only when unpacking such archives to disk may cause issues, however in general Maven plugins don’t unpack archives.

The issue is regarding malicious artifacts and we haven’t been able to create such artifacts with our Maven plugins, hence there’s no additional action required to prevent the creation of malicious archives at this level.

The following plugins use plexus-archiver to unpack dependencies to disk and have been identified as potential triggers for exposing the vulnerability. The matrix contains the name of the component/plugin, which versions are affected, which versions contain the fixed and the link to the corresponding issue.

plugin affected versions fixed version issue details
maven-dependency-plugin (,3.1.0] 3.1.1 MDEP-611 unpack and unpack-dependencies goals (not used unless configured explicitely)
maven-ear-plugin (,3.0.0] 3.0.1 MEAR-268 EAR modules feature (not used unless configured explicitely)
maven-javadoc-plugin [2.5,3.0.0] 3.0.1 MJAVADOC-520 resourcesArtifacts and includeDependencySources features (not used unless configured explicitely)
maven-war-plugin [2.1-alpha-1,3.2.0] 3.2.1 MWAR-416 overlay feature (active by default when packaging=war on dependencies with type=war)
maven-plugin-plugin [3.0,3.5.1] 3.5.2 MPLUGIN-338 scan dependencies sources for javadoc annotations (active by default when packaging=maven-plugin)

Apache Ant up to 1.9.11 has the same issue with its unzip task: it will be fixed in 1.9.12 857095da5153fd18504b46f276d84f1e76a66970.

Then following Maven plugins using Ant are affected:

plugin affected versions fixed version issue details
maven-antrun-plugin (,1.8] MANTRUN-214
maven-plugin-plugin:maven-script-ant [2.0,3.5.2] MPLUGIN-340 Ant Mojo Wrapper

Following plugins use plexus-archiver but are not affected since they only create archives:

  • maven-acr-plugin
  • maven-assembly-plugin
  • maven-ejb-plugin
  • maven-jar-plugin
  • maven-jlink-plugin
  • maven-rar-plugin
  • maven-repository-plugin
  • maven-site-plugin
  • maven-source-plugin

When are you affected by this vulnerability?

The vulnerability is like a Trojan Horse, the malicious archive must first enter the system, normally achieved with a downloaded of a dependency. Once downloaded there’s no direct danger, the user must take some specific actions before becoming a victim. This only happens when all of the following criteria are met:

  • There’s an archive available in a repository that is malicious.
  • Your Maven project or one of its dependencies must find the malicious jar interesting enough to add it as a dependency.
  • There must be a reason to unpack, as defined in the matrix above.
  • The OS must allow the unpack process to put the malicious file at the specified location.
  • The malicious file must be executed or used.

The cause can be described as a breach in the chain of trust. Adding a dependency does imply that you trust it, but also that you trust all of the indirect dependencies. If there’s no trust, you better not add that dependency.