|
|
Subscribe / Log in / New account

Usernames

Usernames

Posted Dec 8, 2024 10:25 UTC (Sun) by excors (subscriber, #95769)
In reply to: Usernames by mathstuf
Parent article: Abusing Git branch names to compromise a PyPI package

> Is `pip` missing hash verification somewhere?

This is getting far beyond my ability to research it with even a little bit of confidence, so you definitely shouldn't trust what I'm saying. But I get the impression that the GitHub Actions pip cache works by caching ~/.cache/pip, which includes both downloaded files and locally-built wheels (to save the cost of rebuilding packages before installing). There's no way to verify the integrity of those wheels, so an attacker tampering with them will cause trouble.

(The download cache may not be very secure either: "By default, pip does not perform any checks to protect against remote tampering and involves running arbitrary code from distributions" (https://pip.pypa.io/en/stable/topics/secure-installs/). It checks the (optional) hashes provided by index servers as "a protection against download corruption", not for security. You can improve that by specifying hashes in the local requirements.txt, though I don't know if verification happens before or after the cache.)


to post comments

Usernames

Posted Dec 8, 2024 14:02 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Hopefully clarifications (and any relevant improvements) can come from trailofbits and others working on the PyPI security story.

Usernames

Posted Dec 8, 2024 22:51 UTC (Sun) by meejah (subscriber, #162580) [Link]

pip can be told to verify the hashes of the wheels it downloads. This isn't necessarily "hard" per se, but is an extra step so many projects don't bother shipping such hash requirements.

That is, an end-user application can ship a "requirements.txt" file that contains hashes for all possible wheels for all exact versions of every requirement, and then pass `--require-hashes`. One problem is that it's "all possible wheels at some point in time" and authors may upload previously-non-existent wheels later.

I don't believe there's any way to declare your dependencies with hashes (e.g. a Python library or application can say "I depend on foo == 1.2.3" but cannot specify the hashes -- and yes, there are usually many because wheels are architecture / platform specific).

Usernames

Posted Dec 8, 2024 23:31 UTC (Sun) by randomguy3 (subscriber, #71063) [Link] (1 responses)

If pip is looking in the cache to satisfy a request for a wheel it would otherwise have downloaded, it will indeed verify that the hash of the local wheel matches the server-reported hash of the file it would have downloaded.

I've occasionally run into this when some badly-behaved project overwrote a wheel (on a company-internal server) and all the builds that had existing caches broke!

Usernames

Posted Dec 8, 2024 23:33 UTC (Sun) by randomguy3 (subscriber, #71063) [Link]

To be clear: the builds broke because in this situation, pip doesn't attempt to fix the cache, but instead errors out (which isn't an unreasonable action from a security standpoint).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds