Aggressive Attack on PyPI Attempting to Deliver Rust Executable (opens in new tab)

My biggest curiosity here is how they generated over a thousand package names ranging from feasible to interesting. I expected gibberish.

Lol, maybe, "chatgpt, give me a thousand feasible pypi package names"?

Thankfully, they're not actually being stolen because all the packages were already taken down; they're available for legitimate use again: https://pypi.org/project/colorslib/

Speaking of LLMs. Since LLMs like to hallucinate every now and then, an LLM could also hallucinate names of packages that it tells people to install. And those packages could in turn have been squatted by malware authors.

And in this way, malicious packages may be unintentionally downloaded by users even when those malicious packages did not yet exist when the LLM was trained. Just because the hallucinated package name was randomly later taken by someone malicious.

You've always been able to make "believable" packages at scale. PyPI doesn't enforce uniqueness: you can crank out malicious near-duplicates of any package you please.

I agree that it is a threat. I don't think this instance is (it's too noisy).

I wrote a comment on the NPM thread earlier (https://news.ycombinator.com/threads?id=freeqaz) that I'll quote here:

> "While being flooded with spam is never good, it gets immediately noticed and mitigated. It's harder for open source projects to spot and stop rare one-offs"

This is the real problem that NPM and other ecosystems face. A determined attacker that is trying to "poison" a popular Open Source package just has to feign as a maintainer long enough to succeed[0]. Defeating these types of attacks will require rethinking how we think about trust of packages.

Projects like Deno are one approach (fork the ecosystem) while projects like Packj (mentioned elsewhere here), Socket.dev, and LunaTrace[1] are taking the other angle (make it harder to install malware).

It's hard to say which approach is better right away. (Probably a hybrid of both, realistically) It's just non-trivial to fix this in one clean swoop. It's messy.

0: https://www.trendmicro.com/vinfo/us/security/news/cybercrime...

1: https://github.com/lunasec-io/lunasec

Me, I just use the stdlib and my local packages.

There's something beautiful in knowing you're using pure, clean Python. Much easier to install, also.

A number of academic researchers (including us) have studied malware samples from past open-source supply chain attacks and identified code/metadata attributes that make packages vulnerable to such attacks. Packj scans for several such attributes to identify insecure or "weak links" in your software supply chain (e.g., missing or incorrect GitHub repo, very high version number, use of decode+exec, etc.). Full list here: https://github.com/ossillate-inc/packj/blob/main/packj/audit...

It's relative, but I assume it's flagging for certain class of known malicious patterns. There's nothing stopping you from writing malicious python code, but essentially that script will only run while you expect it to in most cases unless it interacts with the OS in some way.

It doesn't make plain Python code you blindly execute any safer, but at least you've explicitly given those packages your trust. I believe this is more geared toward detecting compromises of those packages you have given that trust.

Dumpster diving anyone? Npm always felt that way and PyPI is catching up.

"The most beloved programming language used to build and ship malware (PHOTO/VIDEO/NSFW)"

Encrypt my files, but please don't waste my RAM while you do so.

Why not also be sure to mention what OS was used for the build, and what linker, and what file format, and what model of computer was used, and what its default ui language was set to? What is so special about programming language used that sets it apart from those other factors that could be mentioned?

Isn't that because sometimes the tesla software might be at fault?

Yes, but only for the time being. I‘ve recently published a paper on the topic. Rust and Golang are getting immensely popular with malware authors.

I mean, not really? There’s a lot of legacy stuff written in other languages, but malware authors have realized that people are less skeptical of rust and are actively taking advantage of that fact.

The first rule of rust club is that you must talk about rust club.

"no packaging ecosystem does."

This is a little bit too strong, since packaging doesn't require arbitrary code execution. For example, Go doesn't permit arbitrary code execution during `go get`. Now - there have been bugs which permit code execution (like https://github.com/golang/go/issues/22125) but they are treated as security vulnerabilities and bugs.

Of course, you're right about Python.

This seems eminently solvable though. Why can’t every package submission cause some minimal sandboxed docker image to install the package and call the various functions and methods and log all network and disk activity? If anything looks suspicious it would be denied and the submitter would have to appeal it, explaining why the submission is valid. The same applies for NPM and Cargo. I know there is a researcher out there who has retrieved and installed every single pip package to do an analysis, which is a good start. This seems like the kind of thing that wouldn’t even cost all that much, and big corporate users of python would stand to benefit.

> It's impossible to do in the general case if your packaging schema allows arbitrary code execution

Java's type system: ClassLoaders plus SecurityManager was impossible?

that's literally how Java applets worked, enforced through the type system

https://docstore.mik.ua/orelly/java-ent/security/ch03_01.htm

yes, SecurityManager was a poor implementation for many reasons, but it's definitely not "impossible" to sandbox downloaded code from the network while having it interact with other existing code, you can do it with typing alone

I'm not sure it's not do-able, actually. What about having an execution sandbox and a way to check the calls made during the execution of the install script for instance?

I worked a few years back on something like this but it went nowhere, but I still believe it would be doable and useful. The only trace I found back is https://wiki.python.org/moin/Testing%20Infrastructure, which contains almost no info...

obviously, but it allows delegation of trust onto other systems (like the DNS)

example: the package named "aws" on pypi was created by some random guy and has been abandoned for years

if pypi/pip supported namespacing that would be info.randomdude.aws instead

and amazon's packages would be under com.amazon

not being able to namespace internal packages is another security issue that is substantially improved with proper namespacing

to be blunt: not supporting it at this point is reckless and irresponsible

(I note you're part of pypa!)

It can be if you implement it to be so. Just let people create an allowlist of approved vendors for their organization or project from those namespaces. This handles not having to approve individual packages from trusted entities like Google, Microsoft, etc. Update the list when new vendors are needed. Reuse elsewhere as necessary.

Maybe the list can be hosted on an internal server for other employees to reuse. Hosting all the packages internally is overkill. Trusting the world by default is overkill.

Now "pip install gooogle/package"

"Hey User, gooogle/package is not from a trusted namespace. Did you mean google/package which is similar and trusted? Or would you like to add gooogle to your local trust file?"

The lack of any kind of curated feeds that only lists verified or popular packges is tragedy. There should be a reasonable way of allowing clients to protect themselves from a typo.

Namespacing is a lot more than just a theoretical name collision avoider.

Good namespacing (e.g. in Go), in practice, provides critical context about the development/publication of a software package.

I was rolling the shame or guilt card.