CVE-2022-37865 - Path Traversal Vulnerability in Apache Ivy — How Attackers Could Write Files Anywhere On Your System

Apache Ivy is a popular dependency manager for Java projects, relied upon in many build systems for resolving, retrieving, and managing project dependencies. With the release of Apache Ivy 2.4., several new features were introduced — one being the support for optional "packaging" attributes. But, as it often happens, new features sometimes bring new security risks. That’s the case with CVE-2022-37865, a path traversal vulnerability that affects anyone using Ivy versions from 2.4. to 2.5..

This post will explain, in straightforward language, how the vulnerability works, how it can be exploited, and what steps you should take to protect your systems. I’ll include code snippets and links to all original references so you can dig deeper if you wish.

What is CVE-2022-37865?

CVE-2022-37865 is a vulnerability in Apache Ivy where certain archive files (with zip, jar, and war packaging) can be unpacked (“exploded”) into the file system without proper validation of file paths inside the archives.

In plain terms: If a zip (or jar/war) file inside your repository tries to write files outside the intended directory (using paths like ../../../../etc/passwd), Ivy will happily extract those files anywhere that the user running Ivy has write access. This could mean overwriting system files, planting malicious scripts, or tampering with builds — a serious risk in automated build environments.

How Does the Vulnerability Work?

Let’s get specific. Ivy versions before 2.5.1 didn’t check if the file paths inside archives were safe. A malicious archive could be uploaded with entries like ../../evil.sh or /tmp/hack.txt. When Ivy ran and unpacked that archive, it would follow those dangerous paths.

Here’s a simple demonstration of what a malicious zip could look like

my-artifact.zip
├── ../../../../tmp/hacked.txt
├── ../another-dangerous-file.conf
└── normal/dependency.class

When Ivy receives this artifact and is told to unpack it, it will extract

- hacked.txt in /tmp/ (or wherever the traversal leads)

another-dangerous-file.conf outside the intended directory

If your build user has privileges or the paths end up in sensitive locations, you’re in trouble.

You can actually create such a ZIP using Python

import zipfile

with zipfile.ZipFile('malicious.zip', 'w') as zipf:
    zipf.writestr('../../../../tmp/hacked.txt', 'Compromised by CVE-2022-37865')
    zipf.writestr('normal.txt', 'This is a regular file.')

When extracted using a vulnerable version of Ivy, hacked.txt would appear in /tmp/ (on Unix-like systems).

This issue becomes dangerous in the following scenarios

- CI systems: Many continuous integration (CI) environments use Ivy to automatically resolve dependencies. If a malicious artifact is injected or a supply chain attack happens upstream, this vulnerability could be abused to plant files, tamper with builds, or steal secrets.
- Shared Environments: If Ivy is run on shared build agents, attackers could use this bug to overwrite files used by other builds, leading to cross-project contamination.
- Developer Desktops: Even local development machines could be at risk, especially for users running as administrators or with broad directory permissions.

Here’s how an attacker would exploit this

1. Craft a Malicious Archive: The attacker creates a .zip, .jar, or .war file with entries whose names are paths like ../../target_file, pointing outside the intended extraction directory.
2. Upload the Artifact: The archive is published to an Ivy-enabled repository, or replaces a legitimate dependency in a man-in-the-middle attack.
3. Ivy Receives the Artifact: When an Ivy version between 2.4. and 2.5. retrieves and explodes the artifact (due to the new packaging attributes), it unpacks all files, including those with malicious paths.
4. Payload is Delivered: Files end up in dangerous locations on disk, giving the attacker a foothold for further exploitation.

Example Ivy ivy.xml Snippet

<dependency org="evil" name="malicious" rev="1.">
  <artifact name="malicious-artifact" type="zip" packaging="zip"/>
</dependency>

If this artifact references a malicious archive, Ivy will get tricked into exploding it.

Patch and Mitigation

The fix: Version 2.5.1 of Ivy addresses this issue by adding checks to make sure that unpacked files stay within the intended extraction directory. Any attempt to write outside, including with absolute paths or ../ sequences, is now blocked and raises an error.

- Official Ivy Security Advisory (CVE-2022-37865)
- ASF Ivy 2.5.1 Announcement

What should you do?

- Upgrade ASAP: Move to Ivy 2.5.1 or later. If you’re using any version from 2.4. up to 2.5., you are at risk.
- Check your build artifacts: If you control the build pipeline, scan for dependencies that use packaging="zip", jar, or war.
- Restrict repository sources: Use trusted sources, and monitor for unauthorized artifact uploads or modifications.
- Harden build environments: Reduce the privileges of build users and containers so they cannot write to sensitive file system locations.

Conclusion

CVE-2022-37865 is a classic path traversal bug, but with dangerous implications for modern, automated Java build processes. Exploiting it requires only a little knowledge and creativity from an attacker — but fixing it is straightforward: upgrade to Ivy 2.5.1 or newer. Don’t let your project be an easy target in the software supply chain!

Timeline

Published on: 11/07/2022 11:15:00 UTC
Last modified on: 11/08/2022 16:29:00 UTC