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

231–240 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#231

Post by e1g »

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…

Node.js is building something very similar: Permission Model https://github.com/nodejs/security-wg/issues/791

Re: Dozens of malicious PyPI packages discovered targeting developers

#232

Post by dheera »

cozzyd wrote: post #220
dheera wrote: post #200

Earlier quoted context omitted.

Another thing I think might help is (a) Discourage any future use of ">=" in version dependencies. Specify an exact version. That way a future compromised version doesn't get pulled (b) Every build system needs better ways of having multiple versions of a same dependency coexist. I should be able to have one of my project's dependencies depend on "numpy==1.15" and another dependency depend on "numpy==1.16" and they s…

Would you run into dynamic linker problems in this case due to symbol conflicts? Or does symbol versioning magically resolve that somehow?

Prefix all symbols with versions?

foo() becomes v1_15_4_foo() automatically

Re: Dozens of malicious PyPI packages discovered targeting developers

#233

Post by ashishbijlani »

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.

That’s exactly why I use strace-based to sandbox ALL dependencies: https://github.com/ossillate-inc/packj

Re: Dozens of malicious PyPI packages discovered targeting developers

#234

Post by ciupicri »

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…

There were some attempts made for Python 10 - 15 years ago and the conclusions were that it's very hard to do it right. If I remember correctly Zope was using some sandboxing and because of it, it took a while time to catch up with newer versions of Python. You had to compile you own Python because the one that came with the Linux distribution was too new. Also If I'm not mistaking I think that PyPy has some sandboxing.

Anyway I'll leave this from 2013 here:

> After having work during 3 years on a pysandbox project to sandbox untrusted code, I now reached a point where I am convinced that pysandbox is broken by design. Different developers tried to convinced me before that pysandbox design is unsafe, but I had to experience it myself to be convineced.

> It would also be nice to help developers looking for a sandbox for their application. Please tell me if you know sandbox projects for Python so I can redirect users of pysandbox to a safer solution. I already know PyPy sandbox.

-- https://mail.python.org/pipermail/python-dev/2013-November/1...

Re: Dozens of malicious PyPI packages discovered targeting developers

#235

Post by charleslmunger »

jjav wrote: post #179
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.

And it didn't really work in practice. Every callback or thread hop is a security vulnerability by default.

Re: Dozens of malicious PyPI packages discovered targeting developers

#236

Post by jjgreen »

john61 wrote: post #48

This is one reason I prefer Debian python packages.

This really is the sweet spot when production is a specific Debian version, set up your dev environment to match that and it's pretty bombproof. Run CI with pip installs against later Python versions to see the shouty deprecations you'll be able to sidestep.

Re: Dozens of malicious PyPI packages discovered targeting developers

#237

Post by zzzeek »

7373737373 wrote: post #195
zzzeek wrote: post #33

can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .

Identity verification will never be enough, if their account or anything in their development or distribution pipeline is compromised, so will their code. Sandboxing mechanisms are fundamentally required - not only to ward off malicious attacks there, but to prevent accidental side effects and compromise at runtime too.

yes I knew someone would say, "that wont solve the problem!" it would certainly make it way better. it is much more difficult to hack someone's account and bypass their two-factor authentication instead of literally uploading any number of randomly named packages at will.

the same argument can be applied to, "when you park on the street in manhattan, close your windows and lock your doors". Well that won't save your car from being compromised. But it will certainly make it way less likely that someone will steal something out of your car.

Re: Dozens of malicious PyPI packages discovered targeting developers

#238

Post by zzzeek »

robertlagrant wrote: post #82
zzzeek wrote: post #33

can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .

SQLAlchemy can get one for $20/mo : - D

we have more than enough donations to pay for that, and since SQLAlchemy is a "critical project" they'd likely comp us anyway.

but IMO they'd never charge for such a thing, that's not at all in the spirit of OSS / python dev.

Re: Dozens of malicious PyPI packages discovered targeting developers

#239

Post by zzzeek »

dheera wrote: post #71
zzzeek wrote: post #33

can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .

I think the issue isn't so much malicious authors, it's compromised repositories and compromised repositories as dependencies. Blue check would gatekeep a lot of noble, new developers.

these aren't compromised repositories on pypi, these are fully legitimate repos started by bad actors that intentionally use similar sounding names and readmes. a system by which all of the major packages and dependencies are coming in, which to be clear is the whole pile of stuff that people aren't usually looking at, on a set of trusted authors and where someone who is being careful can whitelist specific repos for newer projects they want to use would reduce the problem to almost nothing.

Re: Dozens of malicious PyPI packages discovered targeting developers

#240

Post by nine_k »

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

What if the package is signed by a key available at google.com/pypi/key ?

Actually it should be not just a key but a whole TLS certificate, with references to a CA, activity dates, etc.

Post reply on HN