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

171–180 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#171

Post by louislang »

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…

This is one of the projects we're working on (and open sourcing)!

Currently allows you to specify allowed resources during the package installation in a way very similar to what you've outlined [1].

The sandbox itself lives here [2] and can be integrated into other projects.

1. https://github.com/phylum-dev/cli/blob/main/extensions/npm/P...

2. https://github.com/phylum-dev/birdcage

Re: Dozens of malicious PyPI packages discovered targeting developers

#172

Post by c0balt »

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

Re: Dozens of malicious PyPI packages discovered targeting developers

#173

Post by 7373737373 »

actually_a_dog wrote: post #156
lovelearning wrote: post #47

In a previous HN discussion on the topic of rogue Python packages, readers had suggested bubblewrap and firejail for sandboxing. They limit the access a script and its packages have to your filesystem and network. I think that's the better approach - just assume all packages are malicious by default. Can't rely on scanners because of the large number of packages and attacks.

I agree, "assume unknown, unaudited packages are malicious" is the ideal stance. However, I would say that a simple scanning approach could probably take you pretty far. For instance, if you're not using the requests module or the socket module, chances are pretty good there's no data exfiltration going on. It's absolutely not a foolproof approach, but it is a lightweight layer that can be used in a "defense in depth…

In Python, dynamic imports exist, making this impossible

Re: Dozens of malicious PyPI packages discovered targeting developers

#174

Post by jens0 »

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

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.

Re: Dozens of malicious PyPI packages discovered targeting developers

#175

Post by jerpint »

louislang wrote: post #145
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

npm does something similar with their scoped packages. It fixes the problem for the top level packages, but you'd still have to contend with the transitive dependencies written by smaller organizations or individual contributors. In this case, you have to guarantee that no one involved in the dependency chain ever typos anything.

This is true, and wouldn’t remove the entire space of attack, but would still limit it to some extent.

Re: Dozens of malicious PyPI packages discovered targeting developers

#176

Post by louislang »

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

Phylum's extension framework is built on Deno for this exact reason. The ability to provide granular permissions was something we were really interested in.

Deno is a really cool project, imo.

Re: Dozens of malicious PyPI packages discovered targeting developers

#177

Post by berniedurfee »

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…

Yep, a declarative mechanism would be nice like OAuth scopes.

Though, like scopes, I think many times packages would need broad access, but maybe not?

Re: Dozens of malicious PyPI packages discovered targeting developers

#178

Post by rileymat2 »

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…

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?

Re: Dozens of malicious PyPI packages discovered targeting developers

#179

Post by jjav »

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…

This is essentially the fine-grained control the Java Security Manager enabled. But hardly anyone used it and it was deprecated sadly.

Re: Dozens of malicious PyPI packages discovered targeting developers

#180

Post by actually_a_dog »

7373737373 wrote: post #173
actually_a_dog wrote: post #156

Earlier quoted context omitted.

I agree, "assume unknown, unaudited packages are malicious" is the ideal stance. However, I would say that a simple scanning approach could probably take you pretty far. For instance, if you're not using the requests module or the socket module, chances are pretty good there's no data exfiltration going on. It's absolutely not a foolproof approach, but it is a lightweight layer that can be used in a "defense in depth…

In Python, dynamic imports exist, making this impossible

I don't see how having dynamic imports matters if all you want to do is detect if a specific file is imported. Run the install and see what gets imported. That's it.
Post reply on HN