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

211–220 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#211

Post by zmaurelius »

blktiger wrote: post #105
zmaurelius wrote: post #90

I am really surprised that there haven't been even more malicious packages distributed in the past couple of years considering the rise of cryptocurrency. Seems like a determined and malicious actor could score big by targeting the more popular wallets.

Sonatype found a whole bunch of those and blogged about it in August. https://blog.sonatype.com/more-than-200-cryptominers-flood-n... Disclaimer: I currently work for Sonatype, but in a different area of the company.

Thanks for sharing this, I had no idea it was already this prevalent.

Re: Dozens of malicious PyPI packages discovered targeting developers

#212

Post by coredog64 »

dheera wrote: post #202
plugin-baby wrote: post #154

Earlier quoted context omitted.

> 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 i…

As of Python 3, pip install into the system Python lib directory is strongly discouraged. ISTR that even using pip to update pip results in a warning.

That’s not to say that there’s not still some libs out there that haven’t updated docs to get with the times.

Re: Dozens of malicious PyPI packages discovered targeting developers

#213

Post by ransom1538 »

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…

It's only a matter of time, until, someone with some cash + a good connection to a package just does what is going to happen.

Re: Dozens of malicious PyPI packages discovered targeting developers

#214

Post by p1necone »

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…

You could remove the need to explicitly specify the permissions somewhat by enforcing semver for permission addition.

If you own a package at version 1.X.X and you want to add a permission requirement you have to bump the version to 2.0.0. If you also allow people to opt in to a less strict "auto allow all the currently required permissions for these dependencies" mode, they would at least know for sure nothing can touch anything new unless they explicitly bump the major version.

If you're extra concerned about security you can explicitly specify them so it's really obvious when a major version bump adds new ones, but it removes some of the friction.

Re: Dozens of malicious PyPI packages discovered targeting developers

#215

Post by ratmice »

iudqnolq wrote: post #101
ratmice wrote: post #95

Earlier quoted context omitted.

With rust quite often (e.g. if you are running rust_analyzer) it will run `cargo check`, to produce errors. When `cargo check` is run, build.rs compiled and run. So quite often by step 1, just opening the file in your editor before even making any changes code is compiled and run. Walter's solution here allows the compiler to be used by the editor without the editor being susceptible. Which at the very least negates…

> With rust quite often ... it will run `cargo check` Yup. But making "cargo check" safe while "cargo run" stays vulnerable just reduces the number of times you run malicious code. And whether malicious code runs on my laptop every time I edit a file or every hour or every week makes absolutely no difference. One run and the malware can persist and run whenever it wants going forwards. > Which at the very least negat…

only if you intend to run the program though, if you want to just read the source code, perhaps to see if it contains malicious code you really don't want your editor doing such things by default, so something has to give.

Re: Dozens of malicious PyPI packages discovered targeting developers

#216

Post by musicale »

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 like this. I'd try to keep the permission sets as small, limited, and simple as possible though.

Re: Dozens of malicious PyPI packages discovered targeting developers

#217

Post by namaria »

bt1a wrote: post #87
namaria wrote: post #63

Earlier quoted context omitted.

It might be too cumbersome for most, and I might be more paranoid than average, but each project for me means a fresh VM, a new Keepass database and dedicated accounts. Then again I work mostly in ops, and I've seen first hand how badly things can go wrong so isolation and limiting blast radius takes precedence over daily convenience for me.

Could you please share some resources/tactics for protecting your host machine from these development VMs? If I were to do this, I would want some assurances (never 100%) that my host is protected from the VM to the best of my ability. (If it makes any difference, I would probably be using VMWare Workstation Pro)

I can't give you what you're looking for. You need to decide on the trade offs for yourself. There will always be a risk. Directed attacks can get out of VMs. You could slip up and log into a personal account inside the VM.

Re: Dozens of malicious PyPI packages discovered targeting developers

#218

Post by rollcat »

musicale wrote: post #216
rollcat wrote: post #210

Earlier quoted context omitted.

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 like this. I'd try to keep the permission sets as small, limited, and simple as possible though.

> I'd try to keep the permission sets as small and simple as possible though.

You've described OpenBSD in general. I recommend a deeper dive - it's fantastically refreshing, how simple yet functional an OS can be.

Re: Dozens of malicious PyPI packages discovered targeting developers

#219

Post by namaria »

0cf8612b2e1e wrote: post #136
namaria wrote: post #63

Earlier quoted context omitted.

It might be too cumbersome for most, and I might be more paranoid than average, but each project for me means a fresh VM, a new Keepass database and dedicated accounts. Then again I work mostly in ops, and I've seen first hand how badly things can go wrong so isolation and limiting blast radius takes precedence over daily convenience for me.

That does sound incredibly cumbersome. I suppose that means you are an ace at provisioning machines. How do you move data in/out of the guests? I always found that part of interacting with VMs to be annoyingly painful.

There are always trade offs. You do get better at things you do a lot. My mother won't use a password vault because copying and pasting is too much work for her. I'd just rather pay with my time and inconvenience than one day find out some python package I fiddled with for a late night project once means I need to call my bank.

Re: Dozens of malicious PyPI packages discovered targeting developers

#220

Post by cozzyd »

dheera wrote: post #200
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…

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?
Post reply on HN