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

251–260 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#251

Post by louislang »

0xblinq wrote: post #246
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…

Wouldn't running your development environment inside docker provide the same safety levels?

Containers aren't great security boundaries. To get the safety you'd really need, you should absolutely use a VM.

Re: Dozens of malicious PyPI packages discovered targeting developers

#252

Post by dilawar »

rollcat wrote: post #210
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).

I think @jart has been porting it to Linux https://justine.lol/pledge/ .

Re: Dozens of malicious PyPI packages discovered targeting developers

#253

Post by lovelearning »

unnah wrote: post #77
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.

That's not going to help much if code from the malicious attacker is still going to end up integrated into the software product being built.

Based on my experience, tools like firejail, ebpf, and opensnitch help us keep security in the forefront, train us to verify behavior instead of trusting blindly, and even persuade end users towards that mindset through our installation steps.

If we can spot odd behavior during development and eliminate it from our stacks, the product will be more secure for end users too.

There was a time when convenience overrode any security doubts in my mind. But now I routinely use these tools to restrict access, monitor, and review runtime behavior.

Re: Dozens of malicious PyPI packages discovered targeting developers

#254

Post by lovelearning »

cortesoft wrote: post #125
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.

So that means you can never use any package in code that has to handle sensitive data or manipulate the host machine?

No, it means don't trust it blindly but instead learn techniques to monitor and verify what it does. I use firejail, ebpf, and opensnitch to restrict access, monitor, and verify runtime behavior.

Where possible, persuade end users too to be equally careful. The "linux is safe" cliche blinds both us and end users to its obvious security problems, like running every script as the logged-in user with the same level of access. These malware developers know it and rely on it. That's why we need to move everybody towards a restrict-monitor-verify mindset by default.

Re: Dozens of malicious PyPI packages discovered targeting developers

#256

Post by FractalHQ »

ryukafalz wrote: post #248
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 broadly agree, but if I'm reading your suggestion correctly I think that "access" list is too coarse-grained still! It looks like you're suggesting a predefined list of permissions that can be granted to a dependency, but... why not go even further? If the list of things you're passing in are references rather than strings, then you could do... const apollo = require('apollo-client', {fetch}); const stringutils = r…

I love this idea. But what about peer deps? And their dependencies? What if multiple deps share peer deps? Is there a simple way permissions could be resolved in the web of modules?

Also- tangential but I really wish people would stop using require and use ESM whenever possible. I cringe when I see `require` just as much as when I see `var` being used in 2022, but I’m not certain there’s never a good reason not to use ESM.

Re: Dozens of malicious PyPI packages discovered targeting developers

#257

Post by roflyear »

lgessler wrote: post #149
roflyear wrote: post #117

Once a buddy and I reverse engineered some JS on a site that did the same thing - sent you down one rabbit hole, more obfuscated code, etc.. etc.. we eventually got to the end of it and discovered a comment: // help my name is ### // i am being held at #### (address in china) // please contact my family ### (this was in chinese, we had to translate it) Scary!

So did it seem like some kind of weird scam, or what?

No, maybe a joke? Or serious...

Re: Dozens of malicious PyPI packages discovered targeting developers

#258

Post by lovelearning »

chlorion wrote: post #241
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.

Another good option is to create a new user and run everything under the new UID. Running under a new UID has less chances of accidentally leaving something exposed that can allow for sandbox escape. If you run everything from the new UID, it will mostly be contained to it's own $HOME directory and be unable to modify your user's files or system files. Some distros do not protect home directories from being read so i…

Good insights, thank you!

Re: Dozens of malicious PyPI packages discovered targeting developers

#259

Post by bernawil »

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…

A resource access model for dependencies doesn't make much sense to me, there's basically only 2 things you want to gate access for libraries: filesystem and network. And it's all-in. A library that needs network access may be legit today and after an update start exfiltrating data to a different url. It seems easier to grep for fs and network calls in the library code than any of that.

Re: Dozens of malicious PyPI packages discovered targeting developers

#260

Post by juancampa »

SahAssar wrote: post #205
jens0 wrote: post #174

Earlier quoted context omitted.

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.

This is exactly what I've done for Membrane[0]. It's capabilities based, even to get the time (and thus introduce non-determinism) you need a capability. Dependencies run as separate processes and everything is orthogonally persistent. It's a typescript/javascript system for personal automation built entirely within VSCode. Stay tuned, I'll be posting a video this week.

[0] https://membrane.io

Post reply on HN