A new crop of malicious modules found on PyPI [LWN.net]

Phylum has posted an article with a detailed look at a set of malicious packages discovered by an automated system they have developed.

Similar to this attacker’s previous attempts, this particular attack starts by copying existing popular libraries and simply injecting a malicious __import__ statement into an otherwise healthy codebase. The benefit this attacker gained from copying an existing legitimate package, is that because the PyPI landing page for the package is generated from the setup.py and the README.md, they immediately have a real looking landing page with mostly working links and the whole bit. Unless thoroughly inspected, a brief glance might lead one to believe this is also a legitimate package.

to post comments

A new crop of malicious modules found on PyPI

Posted Nov 2, 2022 19:37 UTC (Wed) by domdfcoding (guest, #159754) [Link] (2 responses)

Presumably the description source (markdown etc.) is *identical* to that of the original package, rather than just producing visually identical HTML? If that's the case it would be trivial to scan newly created projects and compare their description to known good packages - anything that matches is flagged as malicious.

A new crop of malicious modules found on PyPI

Posted Nov 2, 2022 20:03 UTC (Wed) by phlogistonjohn (subscriber, #81085) [Link] (1 responses)

The article notes that the malicious package author, "made a few slight modifications in an effort to make the text consistent with the phony package name it was published under." So some changes were made. Having description text very similar to other packages could probably be part of some malicious package scoring system. Maybe that's part of the toolset that these Phylum folks are building?

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 6:53 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

> Having description text very similar to other packages could probably be part of some malicious package scoring system.

Then you flag the 500 modules that all do colours for terminal and the 5000 who wrap python's http library to provide a different API (numbers made up).

A new crop of malicious modules found on PyPI

Posted Nov 2, 2022 22:18 UTC (Wed) by mss (subscriber, #138799) [Link] (29 responses)

Here we go again.

Another lesson why installed packages should only come from the official distro repository rather than from some uncurated language-specific kitchen sink.

And languages themselves should stop encouraging workflows that include downloading random executable code from the Internet.

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 5:07 UTC (Thu) by irvingleonard (guest, #156786) [Link] (3 responses)

Just forget about portability and deal with all the different versions and package names in different distro versions. Why? Not to mention: what would be the solution for macOS, or Windows?

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 7:16 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

But you can have apt on windows now…

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 16:39 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

I don't know that having software stuffed inside of WSL(2) helps Windows development much myself…

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 21:36 UTC (Thu) by k8to (guest, #15413) [Link]

It helps if you're developing for linux and all you have is a windows laptop. (I'm doing this currently), but even that has weird annoying edge cases, I've found, like non-linux type behvaior with mulitple processes opening the same file, so I think it's best avoided.

For writing python that actually runs on Windows, of course, it's not much help.

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 9:04 UTC (Thu) by NAR (subscriber, #1313) [Link]

Another lesson why installed packages should only come from the official distro repository rather than from some uncurated language-specific kitchen sink.

And that would bring back the available number of libraries to what we had around 2000... For example the Erlang/Elixir ecosystem (which is rather niche) has more than 15000 packages at hex.pm. At a quick glance Debian buster seems to have a few dozen Erlang packages and 0 Elixir packages available.

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 18:11 UTC (Thu) by roc (subscriber, #30627) [Link] (23 responses)

Which official distro repository? There are dozens.

We need better curation in the language-specific library repositories. We shouldn't delegate that to Linux distros, especially because those distros duplicate the work many times for no additional value.

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 19:57 UTC (Thu) by hkario (guest, #94864) [Link] (21 responses)

You don't use dozen distributions in production. Maintain the package for the distribution you're using, don't expect free lunches.

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 20:09 UTC (Thu) by k8to (guest, #15413) [Link]

I've very rarely felt like using the distribution package for whatever you're building to be a good idea.

If you are specifically building something built on a Certain Thing as your main work activity, I've found that invariably you're better off tracking upstream yourself and curating what you deploy yourself.

However, for the Everything Else that your runtime happens to require that you don't really build on relatively directly, it is usually better to rely on a well-curated stream maintained by others, like a production-ready distribution.

I'm pretty sure this is the right path, but it does leave the packages for your language in an muddy gray area, where the most popular have a clear upstream, but smaller ones often just live in language package archive with unclear governance and/or a crufty github repo. This is always gonna be a certain amount of pain. They're not popular enough to get a ton of scrutiny by anyone, in their upstream form or to even get into a distribution. This is the problem area that is being affected by these fake package attacks. If we could get every business running on these bits of code to partly fund them, that would help some, but i don't think it would eliminate the problem at all.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 8:11 UTC (Fri) by roc (subscriber, #30627) [Link] (19 responses)

What if my users use a dozen different distros?

That aside, there is simply no reason why I should do a ton of work to package a lot of crate dependencies for even one distribution. It's busywork that benefits no-one.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 11:15 UTC (Fri) by amacater (subscriber, #790) [Link] (18 responses)

If your users use a dozen distributions - change your users?

In reality, despite the 200++ Linux distributions, there are four or five streams to package for at most.

Debian - and thereby Ubuntu and all derivatives. - .deb

Fedora and the RPM universe - and thereby CentOS Stream, Red Hat .rpm

OpenSUSE - the devs there are good and well motivated (and not Red Hat).

Source based - Arch/Gentoo etc. etc. - ask the communities for help

The first two at least are looking at reproducible builds and that's a very valid use case as outline.
The problem is that PyPi (and Github and a couple of other universes) are just free for all.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 11:34 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (15 responses)

> If your users use a dozen distributions - change your users?

This is a flippant non answer. The impracticality of suggestions like these is why language specific package managers exist and containers (or things like Flatpak) are widely used. Distributions serve the base OS tasks but beyond that, they are largely being bypassed and treated as interchangeable commodities and everything layered on top that users care about more directly is being kept away from distributions. This will continue to happen as long as people whose needs distributions should be serving are being told to lose their users.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 16:13 UTC (Fri) by amacater (subscriber, #790) [Link] (5 responses)

It's not an impractical suggestion - it's one based on experience.

You are associated with Red Hat, as I understand it: get Fedora (and CentOS Stream and thereby Red Hat) working well to package the ecosystems for the various languages - one build will *eventually* percolate to all.

Likewise, building for Debian benefits everything Debian derived.

Likewise: containers solve nothing because they're not well curated or well understood - users generally either use old Docker containers or keep building their own - generally containers aren't patched for security and people don't pull newer versions of containers on a regular basis.

Flatpak is a mess of vendored libraries and a massive size per application in my (biased) opinion: it's also not readily understandable from a security point of view.

PyPi is *still* a free-for-all for typosquatting and similar: Rust and similar impose vendoring issues and it may be that good policies may work for more than one distro.

Distro's aren't (quite) interchangeable commodities - some are well run and care about many aspects, some have too few developers to support them - most seem to die within three or four years.

A new crop of malicious modules found on PyPI

Posted Nov 5, 2022 1:37 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> It's not an impractical suggestion - it's one based on experience.

Distribution developers experience bubble being so disconnected from people enough that you can just think suggesting they just lose users or say that containers solve nothing without understanding why they are popular is part of the problem.

> You are associated with Red Hat, as I understand it

Nope, your understanding there is outdated atleast by a decade.

> one build will *eventually* percolate to all.

No, it won't. Distributions, even the major ones can only package a tiny fraction of any of the language libraries and even then, not the versions developers necessarily want and people don't want it eventually, they want it what they need to use it. This is part of the reason why all recent major languages come with their own package managers and repositories.

Rahul

A new crop of malicious modules found on PyPI

Posted Nov 5, 2022 22:51 UTC (Sat) by mss (subscriber, #138799) [Link]

Distributions, even the major ones can only package a tiny fraction of any of the language libraries
You have just uncovered yet another problem encouraged by these language-specific repositories - huge package fragmentation.

Debian's official repositories carry about 60k packages, Fedora ones about 70k packages, Gentoo has about 20k packages in the main ebuild tree.

On the other hand, PyPI alone apparently has more than 400k packages, crates.io has another 100k, other language-specific repos probably are in the same ballpark.
It should be fairly obvious that nobody can provide a serious per-commit review of that many packages, which is why you end with problems like the one this LWN article is about.

The traditional (known-working) answer to this is to group common functionality into a maintainable and reviewable project like glibc, Glib, GTK+, Qt, kdelibs, Boost, OpenCV, etc.
This way one doesn't need to trust hundreds of contributors to these projects, only a limited group of maintainers of these packages, who do a per-commit review of each contribution before it is accepted into the main repo.

Please note that the traditional problem in OSS is a shortage of maintainers / reviewers - we definitely want to encourage having more of these people in the existing projects.
We don't want encourage people to create yet another NIH "left trim"-type package.

If that means significantly reducing the number of packages then that's a good thing - let's optimize for quality rather than quantity.
This will also help prevent reinventing the square wheel, since these packages very likely have a lot of functionality overlap between them.

By the way, distro package maintentership consists not only of determin[ing] whether Rust library X is non-harmful but also include things like adapting the package to the specific requirements of the particular distro.

In other words, the choices made by the package upstream might not be right for the particular distro target audience.
I mean, just look at how many downstream patches your average popular distro carries.

And don't forget performing an intra-distro integration of packages into a coherent working system - in the end, that's what a distro, in large part, is about.

A new crop of malicious modules found on PyPI

Posted Nov 6, 2022 6:31 UTC (Sun) by oldtomas (guest, #72579) [Link] (2 responses)

"It's not an impractical suggestion - it's one based on experience."

FWIW, I'm firmly in this camp. I don't /want/ my distribution to "be" PyPI. Or npm. Or *gasp* the web browser.

I'm infinitely thankful to Debian folks for keeping a coherent whole.

One data point: a friend of mine wants his small web site "upgraded". It was done back then, Zope, Plone (remember?). Nobody has cared for and fed it for years. No way to reproduce the environment in which that was built. The CADT party has moved on. I'll resort to web scraping to extract the valuable data. The next build will be strictly with stuff available from a distro: whoever is in my situation five years down the road will at least have a fighting chance to use some archives to recreate things.

Another data point: the last Mozilla update greeted me with an ad page "Hey, it's security day!". Folks, go pound sand. My distro doesn't do that. Imagine npm, PyPI, crate-land, CUPS and udev-distro all doing that.

A new crop of malicious modules found on PyPI

Posted Nov 6, 2022 14:02 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> It was done back then, Zope, Plone

Both are still supported ( https://github.com/plone ). Zope is even packaged in Debian.

Walking versions forward would be a problem, but it's going to be a problem with any software. Think about this, because of Plone+Zope your friend had 15 years of uninterrupted service. If they used a packaged CMS, they'd have to upgrade it with every distro release.

A new crop of malicious modules found on PyPI

Posted Nov 7, 2022 4:57 UTC (Mon) by pabs (subscriber, #43278) [Link]

Before you upgrade it, please ask the ArchiveTeam folks to archive your friend's current site to archive.org, so that the current status is fully captured.

https://archiveteam.org/

The Debian snapshot archive would in theory allow someone to add fixes to and rebuild ancient packages on an ancient install of Debian.

https://snapshot.debian.org/

A new crop of malicious modules found on PyPI

Posted Nov 5, 2022 22:19 UTC (Sat) by Vipketsh (guest, #134480) [Link] (8 responses)

> Distributions serve the base OS tasks but beyond that, they are largely being bypassed and treated as interchangeable commodities and everything layered on top that users care about more directly is being kept away from distributions.

I think you are absolutely correct, but are missing one little detail: what is "base OS" and what is something "users care about" is different for every person.

Two random examples: If you are programming in Python, the interpreter and packages you use may be important to you and probably you want to keep up with the latest, not what comes with the OS. On the other hand you may, on rare occasion, want to touch up a photo with gimp, but since you don't care too deeply about image editing, any version which can do a few basic things work for you. At this point you are happy that gimp is part of the "base OS".

On the other hand you may be deeply involved in graphic design and you use gimp on a daily basis. Clearly you will want to keep up with the latest greatest version, not what comes with the OS. Gimp has python script plugins, which you may use or perhaps even write some simple ones. I'm pretty sure you wouldn't want to deal with installing the whole of python and hunt down and keep up to date the packages you need -- the stuff that comes with the "base OS" is your best bet and easiest to use solution.

See ? One man's "base OS" is another's "special care thing". The story could be repeated with webservers, development environments, languages, office suites and pretty much anything in a distribution.

I really think that people need to stop ragging on distributions because they are doing valuable and laborious work, beyond just "base OS", so many of us rely on, even when we don't care to notice.

A new crop of malicious modules found on PyPI

Posted Nov 5, 2022 22:34 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

> Two random examples: If you are programming in Python, the interpreter and packages you use may be important to you and probably you want to keep up with the latest, not what comes with the OS

Sure. This is pretty common.

> On the other hand you may, on rare occasion, want to touch up a photo with gimp, but since you don't care too deeply about image editing, any version which can do a few basic things work for you. At this point you are happy that gimp is part of the "base OS"

Let's say your distribution ships with Flathub enabled (Fedora workstation does that now but with a filter, but let's assume they drop the filter) and you happen to get GIMP from Flathub instead of it being packaged by the distribution, said casual GIMP user is happy with that as well. Except now a GIMP enthusiast can easily install a different version including a nightly build and there isn't any conflict.

> I really think that people need to stop ragging on distributions because they are doing valuable and laborious work

That's part of what I am getting at. Instead of some folks laboriously doing duplicative work translating one metadata to another to fit into the existing packaging model, distributions can either adopt something neutral and focus on the base OS or at the very least, automate most of the mechanical steps that doesn't burn out often scarce volunteer resources.

A new crop of malicious modules found on PyPI

Posted Nov 5, 2022 23:02 UTC (Sat) by gioele (subscriber, #61675) [Link] (1 responses)

> distributions can either adopt something neutral and focus on the base OS [...]

What should be included in this "base OS" that distributions should focus on?

Compiled interpreters (Python, Ruby) without any additional modules? With or without their standard libraries (e.g., unicodedata for Python, or net/https for Ruby)?

A new crop of malicious modules found on PyPI

Posted Nov 6, 2022 3:48 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

> Compiled interpreters (Python, Ruby) without any additional modules? With or without their standard libraries (e.g., unicodedata for Python, or net/https for Ruby)?

Packaging standard library vs just the interpreter isn’t the big difference. All the other thousands of libraries is.

A new crop of malicious modules found on PyPI

Posted Nov 9, 2022 17:32 UTC (Wed) by calumapplepie (guest, #143655) [Link] (4 responses)

Translating metadata is trivial. Most of the work in doing a distribution is in de-vendoring libraries.

Our casual user, who wants GIMP to do a few occasional image edits, might also want GraphViz for occasional visualization of mathematical graphs, Dia for making random diagrams, Chromium for browsing the web, etc. In the distribution model, all those applications share one copy of GTK, one copy of cairo, etc. Gimp even depends on the entirety of GraphViz on Debian. That means that I don't pay the storage space costs of keeping several copies of GTK around, or the memory costs of storing slightly different builds of Cairo for different applications. The user who installs everything via flatpack pays these costs.

The *entirety* of my /usr folder, which includes pretty much every major application or program you'd need (Blender, Gimp, Inkscape, Dia, Libreoffice, Chromium, Firefox, Evolution, Calibre, VLC, Boost, Julia, Rust, KiCad, Jekyll, Wine, Texlive, NodeJS, 2 versions of LLVM and of Java, GCC, GHC, and OCAML, among many others) occupies a grand total of 11 gigabytes on my disk (30 uncompressed, 31 uncompressed and without deduplication). Thats with Steam, Discord, Zotero, and VSCode, which aren't part of my distro and thus vendor a number of dependencies. Also included is the docs for all of those programs.

Pretty much all of those programs, if installed as upstream ships them, vendors a number of dependencies. It is only because of the work of Debian's maintainers that they can all fit on a single hard drive. The hard work of packaging is stripping out vendored dependencies, patching out annoying anti-features, and making sure things obey basic common practices in their building. These efforts are often fairly well deduplicated across distributions: once a Fedora maintainer writes a patch to let a program run with a modern version of libcairo, that patch will often be grabbed by other distributions when they package it.

A new crop of malicious modules found on PyPI

Posted Nov 9, 2022 18:09 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> Translating metadata is trivial. Most of the work in doing a distribution is in de-vendoring libraries.

I have well over a decade of experience as a distribution package maintainer and this isn't my experience at all or anyone I am aware of. Most of the work I did has nothing to do with de-vendoring. There was some of that, sure but nowhere near the majority.

> The user who installs everything via flatpack pays these costs.

You mean Flatpak but they don't. Flatpak has runtimes and file level deduplication via ostree.

A new crop of malicious modules found on PyPI

Posted Feb 21, 2023 22:19 UTC (Tue) by calumapplepie (guest, #143655) [Link]

Sorry, as a "Starving Hacker" I don't get notifications when people reply to my comments.

> Most of the work I did has nothing to do with de-vendoring. There was some of that, sure but nowhere near the majority.

It definitely depends on what you're packaging, but I think I can confidently say that translating metadata isn't the majority of work.

> You mean Flatpak but they don't. Flatpak has runtimes and file level deduplication via ostree.

I have, right now, 19 copies of libGLESv2.so on my system, pulled in by various Electron apps bundling Chromium, occupying a total of 166 MB. They are not identical. One of them, the upstream libGLESv2, is probably incompatible with the others (due to custom Chrome patches), but those others are identical in functionality between themselves. However, my BTRFS system has been unable to deduplicate them. This is because each was built separately; they have slight differences in their compiled code, as well as different values for the build ID which is included in the file.

In other words, file-level deduplication won't prevent this problem (though that doesn't stop me from attempting it): even if its just a different 20-byte .note.gnu.build-id , you still get a failed build (though, I should note that said build id is computed from other parts of the binary, to enable reproducible builds, so its unlikely to be the only thing that changes).

Runtimes sound like an interesting and useful feature; is there an Electron runtime, that includes a full Chrome sandbox? And what does the versioning of runtimes look like? How likely is it for two apps to use the exact same runtime version?

A new crop of malicious modules found on PyPI

Posted Nov 9, 2022 21:25 UTC (Wed) by NAR (subscriber, #1313) [Link] (1 responses)

11 GB is about 5% of the disk in this 7-years old laptop I'm typing right now. 11 GB is about 3 (50-60 minutes longs, 1080p resolution, H.264 codec) episodes of whatever people watching, fetched from torrent. But it doesn't really matter - one thing matters: there's nobody who packages the 100000 packages from language-specific repositories, but developers do use these packages.

A new crop of malicious modules found on PyPI

Posted Nov 10, 2022 0:53 UTC (Thu) by mss (subscriber, #138799) [Link]

11 GB is about 5% of the disk in this 7-years old laptop I'm typing right now

Sharing libraries between packages is not only about reducing the overall disk space usage, but also page cache (RAM) and, most importantly, being able to easily apply security updates.

If there is a CVE (or a bug) in zlib I want to just update the zlib package, rather than having to update 800 packages installed on the system because they bundle this library.

there's nobody who packages the 100000 packages from language-specific repositories, but developers do use these packages.

As I said a few days ago here having such huge package fragmentation makes little sense.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 22:49 UTC (Fri) by roc (subscriber, #30627) [Link]

> change your users

Sorry, I though we were having a serious discussion.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 22:58 UTC (Fri) by roc (subscriber, #30627) [Link]

"Change your users" aside, even if we accept only a few distribution lineages matter, it's still absurd.

We want to support multiple versions of each distribution, and if we add a dependency that wasn't previously packaged for an old distribution, we simply may not be able to continue supporting it.

It's a ridiculous amount of *ongoing* work to deal with the different processes, tools and culture of multiple distributions.

And again, it's simply stupid to duplicate the work of vetting dependencies across multiple Linux distributions. There are valid reasons for having diversity of Linux distributions but "have N different people each independently determine whether Rust library X is non-harmful" isn't one of them.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 4:23 UTC (Fri) by pabs (subscriber, #43278) [Link]

I think we need both, better curation of the language-specific library repositories (especially Reproducible Builds) for those who need this approach, and packaging in Linux distros for those who need this approach.

https://reproducible-builds.org/

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 7:17 UTC (Thu) by pabs (subscriber, #43278) [Link] (3 responses)

Are any tools to detect such malicious modules, or are PyPI reliant on proprietary services to do that?

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 10:38 UTC (Thu) by kleptog (subscriber, #1183) [Link] (2 responses)

There's pip-audit which uses the Python Packaging Advisory Database. So if it's listed in there then you can easy check if you're affected (we do this as part of our build pipeline).

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 1:36 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

I was talking about the stage before that, detecting the malicious code in the first place.

How is that done? Are there any FLOSS tools for that or is PyPI relying on external third parties either manually reading the code, noticing they got hacked, or providing proprietary SaaSS tools that automatically scan all/some of PyPI.

Also, will PyPI ever get reproducible builds of sdists and wheels from the upstream VCS source?

https://reproducible-builds.org/

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 13:29 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> Also, will PyPI ever get reproducible builds of sdists and wheels from the upstream VCS source?

Unlikely. Not all projects support sdists (because `setup.py`/pyproject.toml/whatever file du jour is not the entry point for all projects). Reproducible builds would mean providing some standard environment for all platforms which seems…unlikely.

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 16:31 UTC (Thu) by dharding (subscriber, #6509) [Link] (5 responses)

One way to spot a typo-squatting package is to look at its release history. A well-established package will have a significant history of releases over an extended period of time, something a typo-squatting package cannot replicate. I wonder if this is something that PyPI could highlight on a package's page, something along the lines of "N releases since initial release date".

A new crop of malicious modules found on PyPI

Posted Nov 3, 2022 18:39 UTC (Thu) by bluca (subscriber, #118303) [Link] (2 responses)

Except due to convoluted policy changes many legitimate package authors blew away their package and re-uploaded it to pypi recently to avoid some automated security checks, so even that means nothing.

If only we had a way to distribute curated, carefully selected and trusted software on Linux. We could call it a Linux collection, or a bundle, or maybe something like "distribution". Too bad there isn't any.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 17:50 UTC (Fri) by NAR (subscriber, #1313) [Link] (1 responses)

If only we had a way to distribute curated, carefully selected and trusted software on Linux.

It doesn't really help developers on OS X. And (based on the Stackoverflow survey), there are about as many of them as developers on Linux. Again, based on the Stackoverflow numbers, there's about 75% chance that the creator of a software package doesn't even uses Linux - they won't be bothered to create (and maintain!) Linux packages.

A new crop of malicious modules found on PyPI

Posted Nov 10, 2022 18:49 UTC (Thu) by flussence (guest, #85566) [Link]

Maybe the trillion-dollar company could open their wallet for that one.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 4:21 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

I seem to remember that people have sold or transferred their packages to other people who turned out to be malicious, so typo-squatting (and bit-squatting) aren't the only mechanisms for this, so looking at history isn't a guarantee.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 13:25 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

This seems more common with browser extensions at least.

A new crop of malicious modules found on PyPI

Posted Nov 4, 2022 1:27 UTC (Fri) by deadbeefforever (guest, #161974) [Link]

A quick grep for __import__, system(), exec, subprocess etc. usually gets quite far.

You can download the files from pypi using the browser (without running pip download, because apparently even that tries to run some install hooks) and always glance over the code for suspicious things.