Request for Comment: PyPI Supply Chain Attacks

[JPHutchins]

Hello Poetry Team,

I am working on a series of articles about deploying Python applications with a focus on security. Of course, dependencies and build are managed by Poetry ❤️. This week, as I was working on the security threat modeling for the 2nd article, about deploying to PyPI, news of a very successful supply chain attack was published.

I will be referring to this article throughout, worth the read if you haven't seen it yet: https://checkmarx.com/blog/over-170k-users-affected-by-attack-using-fake-python-infrastructure/

The crux of the supply chain injection was in a requirements.txt (remember those? 😢): changing a domain from pythonhosted.org to pypihosted.org was sufficient to deliver the poisoned colorama to 170,000 users. Imagine if a common dependency, rather than a niche dependency like top-gg's python-sdk, was attacked similarly.

It got me to thinking, does use of Poetry mitigate some of these risks?

Specifically

• Does poetry configure trusted domains that would cause an upstream (supply chain) change to fail?
• Are there other ways that Poetry mitigates this kind of risk? Where does it get the upstream URLs and why can they be trusted?
• Are there plans to strengthen security in the future?

In your answer, please specify if I can quote you in the article, and if so, what your role in the Poetry organization is and how you would like to be credited.

@abn Tagging because you kindly helped me here.

Best regards,
JP Hutchins

[radoering]

If I understand correctly, the attacker had access to the repo and replaced an URL dependency in a requirements.txt with a malicious URL dependency (with a similar URL so it went unnoticed).

The first question that comes to my mind: The attacker could have changed arbitrary code instead of the URL dependency. Is it worth to implement a mitigation for exactly this attack while being vulnerable to each other change the attacker could have made with their gained access?

changing a domain from pythonhosted.org to pypihosted.org was sufficient

Imagine if a common dependency, rather than a niche dependency like top-gg's python-sdk, was attacked similarly.

It's quite uncommon to use URL dependencies in a library package. As far as I know, common dependencies just use name/version dependencies and changing a name/version dependency to an URL dependency will be more obvious so an attacker might add (obfuscated) malicious code directly instead of changing a dependency.

• Does poetry configure trusted domains that would cause an upstream (supply chain) change to fail?
• Are there other ways that Poetry mitigates this kind of risk? Where does it get the upstream URLs and why can they be trusted?
• Are there plans to strengthen security in the future?

Poetry does not configure trusted domains. If a dependency requires an URL dependency it will just be resolved during locking. If you already have an existing lock file with the old correct URL dependency you are safe when installing from it because the URL (and the hash) is locked.

I suppose it would be possible to add the option to configure trusted domains but I'm not sure if it's worth the effort considering that the attacker had the privileges to do arbitrary changes (not just changing dependencies).

[JPHutchins]

Thank you for taking a look!

the attacker had access to the repo

Yes, this is correct. I expected Microsoft to release some comment about how this could have happened but I have not seen anything.

From the article:

"""
The GitHub account of "editor-syntax" was likely hijacked through stolen cookies. The attacker gained access to the account's session cookies, allowing them to bypass authentication and perform malicious activities using the GitHub UI. This method of account takeover is particularly concerning, as it does not require the attacker to know the account's password.
"""

Checkmarx only states that the account was "likely" hijacked through stolen cookies but then goes on to treat it as fact. I know next-to-nothing about web security - my approach has always been to use the latest techniques that the math/security people tell me to, probably implemented in libraries - and my brief research suggests that there are many ways to mitigate this kind of session hijacking. I suspect that GitHub's account security is good 💸.

So I will tell readers the standard: don't reuse passwords, use 2FA, etc...

common dependencies just use name/version dependencies and changing a name/version dependency to an URL dependency will be more obvious

This is the advantage that I felt Poetry (or pyproject.toml) has. Assuming that the dependency URL would be resolved by PyPI or some other package repository, then a change from colorama >= 0.4.3 -> colorama = { url = "https://pwned.com/colorama.tar.gz" } is much more obvious than changing a few characters in an existing URL. Going out on a limb... maintainers would have noticed the nefarious commit sooner.

JP

[dimbleby]

Assuming that the dependency URL would be resolved by PyPI or some other package repository, then a change from colorama >= 0.4.3 -> colorama = { url = "https://pwned.com/colorama.tar.gz" } is much more obvious than changing a few characters in an existing URL

I don't think that's the right comparison.

It's not usual practice to provide urls in requirements.txt either. A typical requirements.txt also says colorama >= 0.4.3 or whatever, and then the same reasoning applies about the malicious change being more obvious. The attacker had to seek out requirements.txt that do this unusual thing, and target those projects.

But they might as well have looked for pyproject.toml that do the equally unusual thing of specifying a url - I suppose they exist in the wild too. And in those places, presumably, changing one url to another would have been just as conspicuous or inconspicuous as it was in the actual attack.

[JPHutchins]

Good point, I will make sure to point that out! I’ll check their git history and see what might have lead them down this path.

[JPHutchins]

Does Poetry support configuration of trusted hosts in the pip.conf of the venv?

https://pip.pypa.io/en/stable/topics/configuration/

[dimbleby]

pip.conf is pip configuration, it has nothing to do with poetry

[JPHutchins]

It seems like Poetry does support some constraints on the sources of packages. Can you comment on using explicit package sources or package source constraint to require that packages are from PyPI (or other explicit sources)? Is it not capable to pass the requirement to upstream dependencies?