Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dozens of malicious PyPI packages discovered targeting developers

blog.phylum.io

Post reply on HN
Print view View original

201–210 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#201

Post by nl »

insanitybit wrote: post #185
rileymat2 wrote: post #178

Earlier quoted context omitted.

I thought that Java Applets (and maybe flash, I am less familiar) had an advanced security model, but it was exploit after exploit because of the huge attack surfaces? I suspect you may run into similar sandbox escapes once things are complicated enough. So it seems like a good idea if they can be made bug free, but good luck with that?

Part of the problem with the Java sandbox is that it was enforced entirely by the VM + the VM is written in C++. The idea is not inherently bad.

It's been a while since I worked in this area but my recollection was that most JVM security issues in this areas were bypasses of the Java Security Manager often by confusing it about code origin. That's all Java code, not C++.

Re: Dozens of malicious PyPI packages discovered targeting developers

#202

Post by dheera »

plugin-baby wrote: post #154
heleninboodler wrote: post #144

This type of stuff is one reason I like vendoring all my deps in golang. You have to be very explicit about updating dependencies, which can be a big hassle, but you're required to do a git commit of all the changes, which gives you a good time to actually browse through the diffs. If you update dependencies incrementally, it's not even that big a job. Of course, this doesn't guarantee I won't miss any malicious code…

> And why is nodejs so much more dependency-happy than python? Could it be that nodejs has implemented package management more consistently and conveniently than other languages/platforms?

pip throws your dependencies in some lib directory either on your system (default if you use sudo), in your home directory (default if you don't use sudo), or inside your virtualenv's lib directory.

npm pulls dependencies into node_modules as a subdirectory of your own project as default.

Python really should consider doing something similar. Dependencies shouldn't live outside your project folder. We are no longer in an era of hard drive space scarcity.

Re: Dozens of malicious PyPI packages discovered targeting developers

#203

Post by comprev »

c0balt wrote: post #172
erustemi wrote: post #166

I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…

At the beginning the permissions aspect of deno[0] was actually on of the major selling points for me. The approach used there was to begin at zero and offer granular permission control, e.g. `--allow-read=data.csv`, for filesystem, network etc. I would love to have this for, e.g., python or npm packages. [0]: https://deno.land/manual@v1.27.0/getting_started/permissions

Interesting read, thanks.

Re: Dozens of malicious PyPI packages discovered targeting developers

#204

Post by insanitybit »

nl wrote: post #201
insanitybit wrote: post #185

Earlier quoted context omitted.

Part of the problem with the Java sandbox is that it was enforced entirely by the VM + the VM is written in C++. The idea is not inherently bad.

It's been a while since I worked in this area but my recollection was that most JVM security issues in this areas were bypasses of the Java Security Manager often by confusing it about code origin. That's all Java code, not C++.

It's been so long I could be remembering incorrectly.

Re: Dozens of malicious PyPI packages discovered targeting developers

#205

Post by SahAssar »

jens0 wrote: post #174
c0balt wrote: post #172

Earlier quoted context omitted.

At the beginning the permissions aspect of deno[0] was actually on of the major selling points for me. The approach used there was to begin at zero and offer granular permission control, e.g. `--allow-read=data.csv`, for filesystem, network etc. I would love to have this for, e.g., python or npm packages. [0]: https://deno.land/manual@v1.27.0/getting_started/permissions

Doesn't this only apply to the entire process? Not the individual dependencies, right? Just confirming, Deno was my first thought with this, it requires the developer to deliberately enable permissions needed.

Yes, it applies to the whole process. It's incredibly hard to sandbox dependencies individually since you don't know how your code or other dependencies interact with it. If you want you can run dependencies in a worker process and sandbox that tighter, but that is quite a bit of work.

Re: Dozens of malicious PyPI packages discovered targeting developers

#206

Post by yamtaddle »

heleninboodler wrote: post #144

This type of stuff is one reason I like vendoring all my deps in golang. You have to be very explicit about updating dependencies, which can be a big hassle, but you're required to do a git commit of all the changes, which gives you a good time to actually browse through the diffs. If you update dependencies incrementally, it's not even that big a job. Of course, this doesn't guarantee I won't miss any malicious code…

> And why is nodejs so much more dependency-happy than python?

Part of it—but I'm sure not all—is that the core language was really, really bad for decades. Between people importing (competing! So you could end up with several in the same project, via other imports! And then multiples of the same package at different versions!) packages to try to make the language tolerable and polyfills to try to make targeting the browser non-crazy-making, package counts were bound to bloat just from these factors.

Relatedly, there wasn't much of a stdlib. You couldn't have as pleasant a time using only 1st-party libraries as you can with something like Go. Even really fundamental stuff like dealing with time for very simple use cases is basically hell without a 3rd party library.

Javascript has also been, for whatever reason, a magnet for people who want to turn it into some other language entirely, so they'll import libraries to do things Javascript can already do just fine, but with different syntax. Underscore, rambda, that kind of thing. So projects often end up with a bunch of those kinds of libraries as transitive dependencies, even if they don't use them directly.

Re: Dozens of malicious PyPI packages discovered targeting developers

#207

Post by jve »

kibwen wrote: post #56
coffeeblack wrote: post #3

I started to develop only inside VMs, with a full Desktop, IDE, browser etc. inside the virtual machine. There have been to many contaminations of major package repos lately. Only one typo in an import statement up the dependency chain and you’d be compromised.

This is a good approach, though presumably the VM still has access to your Github credentials (via the browser) and your SSH keys? It'll limit the fallout of getting owned to anything reachable from Github (is it against Github's TOS to have multiple accounts?), less if you have 2FA (does there exist 2FA for SSH keys (I don't mean passphrases)?), but I think it would be better for just my build/run/test cycles to be…

> does there exist 2FA for SSH keys (I don't mean passphrases

Yes. Yubikey. ecdsa-sk key requires you to tap yubikey to have a working key. It consists of 2 parts - a private key file, but which is useless without yubikey. https://developers.yubico.com/SSH/

https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...

Re: Dozens of malicious PyPI packages discovered targeting developers

#208

Post by comprev »

YetAnotherNick wrote: post #157
jerpint wrote: post #137

I wonder why we can’t have pip packages be published by username or organization, like pip install google/tensorflow It would significantly reduce the attack space

It gives false sense of security. What about google_official/tensorflow

Perhaps something like Docker hub where "official" images are like "/_/nginx"

So "_google/tensorflow" would be official.

"google/tensorflow" would not be (plus it would be reserved by default to avoid confusion).

Re: Dozens of malicious PyPI packages discovered targeting developers

#209

Post by jve »

kibwen wrote: post #56
coffeeblack wrote: post #3

I started to develop only inside VMs, with a full Desktop, IDE, browser etc. inside the virtual machine. There have been to many contaminations of major package repos lately. Only one typo in an import statement up the dependency chain and you’d be compromised.

This is a good approach, though presumably the VM still has access to your Github credentials (via the browser) and your SSH keys? It'll limit the fallout of getting owned to anything reachable from Github (is it against Github's TOS to have multiple accounts?), less if you have 2FA (does there exist 2FA for SSH keys (I don't mean passphrases)?), but I think it would be better for just my build/run/test cycles to be…

Github offers fine grained personal access tokens. https://docs.github.com/en/authentication/keeping-your-accou...

Azure DevOps does it too

Re: Dozens of malicious PyPI packages discovered targeting developers

#210

Post by rollcat »

erustemi wrote: post #166

I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…

Check out OpenBSD's pledge(2): https://man.openbsd.org/pledge.2

It does exactly that (although on a per-process basis).

I don't think this kind of permission system can be retrofitted into an existing language without direct OS support, and probably not at the library level (you'd need something like per-page permissions which would get hairy real fast).

Post reply on HN