Directory Traversal Affecting setuptools package, versions [38.2.3,84.1.0)

Affected versions of this package are vulnerable to Directory Traversal via _fix_namespace_packages in setuptools/wheel.py during legacy wheel installation. Entries in a wheel's namespace_packages.txt are split on . and passed directly to os.path.join, which interprets its arguments as filesystem paths. An entry that is absolute, drive-qualified, or UNC causes os.path.join to discard the destination egg directory entirely, allowing the wheel to place a fixed-content __init__.py at an arbitrary path on the filesystem with the permissions of the installing process.

Note: This is only exploitable through the deprecated setup_requires mechanism when setup() is invoked outside a PEP 517 frontend; the setuptools build backend never reaches this code path. The target parent directory must already exist.

The reproduction was performed entirely inside a disposable temporary directory.

Layout:

sandbox/
    destination/
    outside/
    input/
    canary.txt

A synthetic wheel was created containing:

demo_pkg-1.0.dist-info/namespace_packages.txt

whose content was the absolute path of:

sandbox\outside

The real acquired setuptools implementation was then invoked:

setuptools.wheel.Wheel(synthetic_wheel).install_as_egg(
    sandbox_destination
)

The operation completed without exception.

Expected metadata was created under:

sandbox\destination\EGG-INFO

but setuptools also created:

sandbox\outside\__init__.py

The file did not exist before execution.

Its contents were:

__import__('pkg_resources').declare_namespace(__name__)

The unrelated canary remained byte-identical.

The sandbox was deleted after recording the evidence.

Impact
A crafted wheel can cause setuptools to create a fixed-content
__init__.py outside the intended installation directory at a
filesystem path influenced by the wheel, with the permissions of the
process performing the installation.
The demonstrated reproduction required the target parent directory to
already exist.
Note: The PoC states it was performed inside a disposable temporary directory using a synthetic wheel with an absolute path as the namespace package entry, invoking Wheel.install_as_egg directly; no specific OS, Python, or setuptools version is stated.

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

• Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

• Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

• GitHub Advisory
• GitHub Commit
• GitHub PR
• GitHub Release