[HN Gopher] PyPI halted new users and projects while it fended o...
___________________________________________________________________
PyPI halted new users and projects while it fended off supply-chain
attack
Author : consumer451
Score : 26 points
Date : 2024-03-28 20:14 UTC (2 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| cjk2 wrote:
| Am I the only one who is scared by the entire ecosystem of "drag
| random crap and dependencies off the Internet from who the hell
| knows"?
|
| I've had a couple of minor incidents with NodeJS dependencies
| over the last few years on this front which sort of opened my
| eyes to running untrusted code. I tend to err on the side of
| distribution packages since, with the restrictions that imposes
| on what I do.
| nerdwaller wrote:
| Some packaging ecosystems are more risky than others, primarily
| because they allow running arbitrary code at some point during
| the install cycle. Node and Python being two notable ones,
| especially considering how commonly they are used[1]. Others do
| it more safely where, at a minimum, no code can run until the
| library is imported and run with application code.
|
| Depending on how and where you deploy, you can mitigate some of
| that by isolating the installs and not keeping sensitive
| information there (e.g. in a docker image).
|
| [1] - I don't follow node/npm closely anymore, so this may have
| changed.
| louislang wrote:
| this is still true of node/npm. It's also true of Cargo
| (Rust), Nuget (C#), and a handful of others. I'd say it's
| probably the _norm_ for most ecosystems to allow some form of
| pre/post-install execution.
| Denvercoder9 wrote:
| I'm not convinced of the additional danger in letting
| packages run code during installation. You install them
| because you want to use them, so the code they ship will get
| run anyway. Are there really common environments where the
| final product _only_ gets run with less permissions than the
| package manager?
| taeric wrote:
| Most any deployment based setup will have a separation
| between the code that is executed on the developer's
| machine and the code that is run on a built application?
|
| Yes, it is common for developers to have some unit/build
| testing setup available so that they can run the code
| locally, but even that should be done by a system that
| makes sure anything actually running during the test is
| declared as part of the project workspace.
|
| More directly, it is common for many package managers to
| try and do a global install of some things. If not global
| for the computer, for the current user. Thankfully, this is
| changing a lot. (At least, I think it is?)
| dns_snek wrote:
| How does that add any danger? You're pulling in code
| because you want to use it. If the package is malicious
| and your package manager doesn't have post-install
| scripts, the malicious code is just going to run 5
| seconds later when you import it and start working with
| it.
|
| In the case of NPM with post-install scripts disabled,
| you'll simply get pwned when you `npm start` rather than
| `npm install`.
| taeric wrote:
| Honestly, I'm going off memory on python. In the olden
| days, it was not at all uncommon for devs to want the
| ability to "sudo pip install foo".
| Denvercoder9 wrote:
| Deployments are irrelevant for this conversation;
| libraries get to run code there anyway. For code
| execution during installation to be an attack vector,
| you'd need an environment where _npm install_ gets run
| with _more_ permissions than _npm start_ (or the
| equivalent for other package managers). I can 't really
| think of an environment where that is the case. Usually
| the build and package manager is more restricted than the
| application, not the other way around.
| taeric wrote:
| Right, my understanding is that this was not too uncommon
| for some older packages? Especially in early python, it
| was not too uncommon to accidentally install to the whole
| system, no?
| lmm wrote:
| > Are there really common environments where the final
| product only gets run with less permissions than the
| package manager?
|
| Yes, only running the final product in a VM/container is
| pretty common.
| seabrookmx wrote:
| You're not the only one!
|
| This is why I strongly prefer languages with a comprehensive
| standard library. I trust my Python/golang/dotnet/whatever
| install, so the number of third party packages I need to pull
| in is much smaller and more easily audited.
| mooreds wrote:
| What is your audit schedule/process?
| JohnFen wrote:
| You're not the only one. I have become hesitant to use
| applications developed in certain languages and ecosystems
| (like Python) because they encourage the prolific use of
| unvetted code not under the control of the developer, although
| there is no real safe space anymore. It's a cultural shift that
| has affected almost everything.
| mopsi wrote:
| Looks absolutely insane to me too. Recently I had to deal with
| a NPM-based theme for a minor website. It downloaded 140
| dependencies. Most of them were trivial like "string-width",
| which finds the visual width of a character (some Unicode
| characters may appear as double-width). The package consists of
| a rather simple 25-line function that tests a character against
| several if-s in a loop. A function that trivial does not
| justify adding +1 to the potential sources of supply-chain
| attacks.
| ashishbijlani wrote:
| I've been building Packj [1] to detect such attacks. Packj can
| flag malicious, abandoned, typo-squatting, and other "risky"
| PyPI/NPM/Ruby/PHP dependencies. We use static, dynamic, &
| metadata analysis to scan for indicators of compromise (e.g.,
| spawning of shell, use of SSH keys, network communication, use of
| decode+eval, etc.) OR presence of vulnerabilities.
|
| 1. https://github.com/ossillate-inc/packj
| throwaway458864 wrote:
| I think people should stop using PyPI altogether. It's full of
| abandoned garbage and malware because there's really no filter on
| who can upload what. I don't even use it to search for packages
| anymore.
|
| If Linux distro packaging worked the same way, Linux would be a
| hellscape of malware and weird random broken apps. I'd rather use
| old software than constantly worry about fat fingering a package
| name and ending up with a crypto miner on a thousand machines.
| Thank goodness for that culture of vetting packages.
| Handprint4469 wrote:
| Isn't this the case for most programming languages' package
| indices? crates.io for Rust, the NPM registry for Javascript,
| etc. They are all public in the sense that anyone can just
| create an account and upload a package.
| lmm wrote:
| Maven Central is notoriously fiddly to get an account for -
| it require a manual registration step and you have to GPG-
| sign all your packages. Seems like that barrier to entry may
| have been useful.
| teddyh wrote:
| Fun fact: Unix _used to_ work in slightly this way. You'd see
| something neat on comp.sources.unix, download it, and if it was
| useful, deploy it on your site for your local users. A bit
| later, huge FTP sites with everything ever written for Unix
| were routinely used as package repositories are used today.
| Modern Linux (and other Unices) distributions, with
| maintainers, strict inspection, limits on what programs can do,
| etc. came _as a reaction_ to the obvious problems with that. It
| always seems to me that language-specific ecosystems like PyPI
| (RIP Cheese Shop), NPM, crates.io, etc. have not yet learned
| this lesson.
| halfcat wrote:
| > I think people should stop using PyPI altogether
|
| Sorry if this is a naive question, but what would the
| alternative be?
| louislang wrote:
| I'm one of the co-founders @ Phylum. We've been tracking this
| campaign [1] (along with several other unrelated ones). The
| collective group of security researchers (Shoutout to
| https://vipyrsec.com/) in our Discord have been reporting these
| packages to PyPI for removal. If this is something you'd be
| interested in helping with, please join our Discord
| (https://discord.gg/Fe6pr5eW6p)!
|
| Besides the gigantic analytics platform we've constructed to
| monitor supply chain attacks targeting open source, we've also
| open sourced a few tools to better mitigate attacks targeting
| developers. For example, a sandbox to minimize the impacts of
| malicious packages during installation [2] (with a pre-check to
| our API for known malware), which allows you to do things like
| phylum npm install <pkgName>
|
| Happy to answer any questions about this campaign or others we've
| uncovered!
|
| 1. https://blog.phylum.io/typosquatting-campaign-targets-
| python...
|
| 2. https://github.com/phylum-dev/birdcage
___________________________________________________________________
(page generated 2024-03-28 23:01 UTC)