CVE-2023-45805 in pdm
Summary
by MITRE • 10/25/2023
pdm is a Python package and dependency manager supporting the latest PEP standards. It's possible to craft a malicious `pdm.lock` file that could allow e.g. an insider or a malicious open source project to appear to depend on a trusted PyPI project, but actually install another project. A project `foo` can be targeted by creating the project `foo-2` and uploading the file `foo-2-2.tar.gz` to pypi.org. PyPI will see this as project `foo-2` version `2`, while PDM will see this as project `foo` version `2-2`. The version must only be `parseable as a version` and the filename must be a prefix of the project name, but it's not verified to match the version being installed. Version `2-2` is also not a valid normalized version per PEP 440. Matching the project name exactly (not just prefix) would fix the issue. When installing dependencies with PDM, what's actually installed could differ from what's listed in `pyproject.toml` (including arbitrary code execution on install). It could also be used for downgrade attacks by only changing the version. This issue has been addressed in commit `6853e2642df` which is included in release version `2.9.4`. Users are advised to upgrade. There are no known workarounds for this vulnerability.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2023
The vulnerability described in CVE-2023-45805 represents a sophisticated supply chain attack vector within the Python package management ecosystem, specifically targeting the pdm dependency manager. This flaw stems from an improper validation mechanism in how pdm processes version identifiers within lock files, creating a discrepancy between how PyPI interprets package identifiers and how pdm resolves them during installation. The vulnerability operates through a clever manipulation of package naming conventions that exploits the difference in version parsing logic between the two systems, allowing malicious actors to craft deceptive package dependencies that appear legitimate but actually install malicious code. This issue directly violates the fundamental principle of package integrity that users expect when managing Python dependencies through modern tools.
The technical flaw manifests in the version parsing and matching logic where pdm accepts version strings that are not properly normalized according to PEP 440 standards, specifically allowing version identifiers like "2-2" that PyPI would reject but pdm would process. The vulnerability exploits a mismatch between the filename convention used in PyPI packages and how pdm interprets the same package identifier during dependency resolution. When a malicious actor creates a package named "foo-2" with a tarball filename "foo-2-2.tar.gz", the system treats this as version "2-2" for pdm while PyPI sees it as version "2" for project "foo-2". This discrepancy enables attackers to bypass security checks and install malicious code under the guise of trusted dependencies, creating a significant risk for any system that relies on pdm's lock file integrity for dependency management.
The operational impact of this vulnerability extends far beyond simple code substitution, as it enables arbitrary code execution during the dependency installation process and provides a pathway for downgrade attacks that can compromise system security. Attackers can craft malicious lock files that appear to reference legitimate packages from trusted sources while actually installing compromised versions, potentially leading to complete system compromise. The vulnerability affects the core trust model of package management systems, undermining the security assumptions that developers make when specifying dependencies in their pyproject.toml files. This type of attack falls under the ATT&CK framework's software supply chain compromise category, specifically targeting the dependency management and package installation phases where attackers can manipulate the software delivery pipeline to introduce malicious code.
The mitigation strategy for this vulnerability requires immediate upgrading to pdm version 2.9.4, which includes the fix implemented in commit 6853e2642df. The fix addresses the core issue by requiring exact matching of project names rather than just prefix matching, ensuring that package identifiers are properly validated against established naming conventions. This aligns with CWE-20: Improper Input Validation, which specifically addresses the need for robust validation of input data to prevent manipulation of system behavior. Organizations should also implement comprehensive monitoring of their dependency management processes and consider additional security measures such as package signature verification and integrity checking. The vulnerability demonstrates the critical importance of maintaining strict adherence to PEP standards in package management tools and highlights the need for continuous security auditing of dependency resolution mechanisms. Given that no workarounds exist for this specific vulnerability, organizations must prioritize immediate remediation to protect their software supply chains from potential exploitation.