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

221–230 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#221

Post by cozzyd »

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…

Have you seen how much space a virtualenv uses? It can easily be >1 GB. For every project, this adds up. (Not to mention the bandwidth, which is not always plentiful).

Re: Dozens of malicious PyPI packages discovered targeting developers

#223

Post by MikePlacid »

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…

> 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 should be able to coexist in the SAME environment

Now I see what people at one respectable, big project were thinking when they allowed 7 different versions of OpenSSL to be statically linked to the same executable…

Seriously, this idea may save you from some not very interesting work, but it will create the need of much bigger amount of work which while potentially interesting is not very productive. You are toying with exponential growth here, like a chain reaction - like a bomb.

Re: Dozens of malicious PyPI packages discovered targeting developers

#224

Post by fbhabbed »

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.

SSH.

Doesn't even need to be command line, you can just open remote addresses in your favourite graphical file browser, at least under Linux.

Re: Dozens of malicious PyPI packages discovered targeting developers

#225

Post by weberer »

cozzyd wrote: post #189
YetAnotherNick wrote: post #157

Earlier quoted context omitted.

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

google.com/tensorflow (and you'd have to prove you own google.com) not perfect, but better.

I've always been a fan of how Java packages do it where the TLD is first.

Re: Dozens of malicious PyPI packages discovered targeting developers

#226

Post by 323 »

RockRobotRock wrote: post #31

The guy who runs the C2 openly has the source code for the stealer on his GitHub. Why doesn't GitHub do anything about this shit? I've personally been hacked by a supply chain attack via a GitHub wiki link. I contacted GitHub support and didn't hear back from them for 3 months. They are completely useless.

The standard HN answer is because freedom of speech. That the problem is the one using the code, not the code itself.

Re: Dozens of malicious PyPI packages discovered targeting developers

#227

Post by bigbillheck »

A lot of people in the comments here aren't happy with people using tons of dependencies, but what else do you expect from ecosystems that (a) make it easy to download and publish packages and (b) don't have much of (b') a standard library or (b'') set of blessed solutions?

This isn't a case of 'oh, python (javascript, etc) programmers are dumb and lazy'. If C++ had a packaging system and it wasn't so horrible to add third party dependencies we'd be seeing the same thing there.

Re: Dozens of malicious PyPI packages discovered targeting developers

#228

Post by insanitybit »

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.

I disagree. I need to write this up in more detail but it helps quite a lot.

1. An attacker who can access your development environment and your production environment is worse than one who can only access your production environment. You might say "but the end goal is prod", but it's not that simple because of (2).

2. We already have very good tooling for isolating services at runtime. Separating them onto different instances, firewall/security groups, limited API keys, docker/ containers, apparmor, selinux, etc. We have a lot of tooling for "a service in production is owned". What we lack is "a library in dev environment is owned".

3. Devs often have more privileges than your services. It's unfortunate but at a lot of companies, perhaps given some lateral movement around dev envs, you'll find SSH keys to production, browser session cookies that give you console access, source code, chat sessions, internal documents, git keys, gpg keys, etc.

So I'm actually fine with a tool that sandboxes the build process but leaves open the hole of "but the attacker can patch the binary and execute code in production". That's a huge win.

Re: Dozens of malicious PyPI packages discovered targeting developers

#229

Post by dheera »

cozzyd wrote: post #221
dheera wrote: post #202

Earlier quoted context omitted.

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…

Have you seen how much space a virtualenv uses? It can easily be >1 GB. For every project, this adds up. (Not to mention the bandwidth, which is not always plentiful).

4TB hard drives are $300 these days.
Post reply on HN