Path traversal in PackageIndex.download leads to Arbitrary File Write.

[jaraco]

Vulnerable Code

    def _download_url(self, url, tmpdir):
        # Determine download filename
        #
        name, _fragment = egg_info_for_url(url)
        if name:
            while '..' in name:
                name = name.replace('..', '.').replace('\\', '_')
        else:
            name = "__downloaded__"  # default if URL has no path contents

        if name.endswith('.[egg.zip](http://egg.zip/)'):
            name = name[:-4]  # strip the extra .zip before download

 -->       filename = os.path.join(tmpdir, name)

Here: https://github.com/pypa/setuptools/blob/main/setuptools/package_index.py#L823

os.path.join() discards the first argument (tmpdir) if the second begins with a slash or drive letter.
name is derived from a URL without sufficient sanitization. While there is some attempt to sanitize by replacing instances of '..' with '.', it is insufficient.

PoC

Attached.
The script downloads a file from a local HTTP server using setuptools' PackageIndex bypassing tmp directory restrictions, and writing to a sensitive location.

$ python poc.py
Payload file: http://localhost:8000/%2fhome%2fuser%2f.ssh%2fauthorized_keys
Written to: /home/user/.ssh/authorized_keys

Risk Assessment

As easy_install and package_index are deprecated, the exploitation surface is reduced.
However, it seems this could be exploited in a similar fashion like CVE-2022-40897, and as described by POC 4 in CVE-2024-6345 report: via malicious URLs present on the pages of a package index.
https://huntr.com/bounties/d6362117-ad57-4e83-951f-b8141c6e7ca5

Impact: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context.

[WilliamRoyNelson]

@jaraco Would it be possible to backport this fix to 75.3.x for Python 3.8 support?
I know Python 3.8 reached End of Life in 2024, but virtualenv still supports it:
https://github.com/pypa/virtualenv/blob/2ec4db5d60d9374a0869703c757ead04a7b67c84/src/virtualenv/seed/wheels/embed/__init__.py#L8-L13

It looks like their policy is to support Python versions for 18 months after EOL:
pypa/virtualenv#2526 (comment)

And because setuptools 75.3.2 is bundled with virtualenv, it causes problems with vulnerability scanning tools.

[jaraco]

And because setuptools 75.3.2 is bundled with virtualenv, it causes problems with vulnerability scanning tools.

Unfortunately, no backport will fix versions pinned to the vulnerable versions.

See the referenced issue where we're exploring options for a backport.