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

191–200 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#191

Post by louislang »

qwertox wrote: post #186

Couldn't forcing publishers to sign a hash of the module not be a solution? The certificate could contain information about the owner and the consumer could check if he wants to deal with the owner or not. Developers could add a desired whitelist to pip (or use a curated one) to continue using automation.

Hashing solves one side of the coin. Namely, whether or not you got the thing you expected (or perhaps, got the thing you expected from the individual you expected it to come from).

On the other side, we have to contend with the fact that malware can be slipped into otherwise legitimate packages. This has happened numerous times over the years. In this case, the hash would serve as a way to say "yup, you definitely got malware". Useful for incident response, but I think we can do better and try and prevent these attacks from being viable in the first place.

Re: Dozens of malicious PyPI packages discovered targeting developers

#192

Post by nicoty »

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 watched a video[0] about the Roc language recently, and they do something interesting to address this: they have a layer in their language called "platforms" and the idea behind these are that there are many different platforms that you can choose between to run code with and each one has different permissions. So one platform might be sandboxed and disallow the use of certain unsafe APIs whereas another might be less sandboxed.

[0] https://m.youtube.com/watch?v=cpQwtwVKAfU

Re: Dozens of malicious PyPI packages discovered targeting developers

#193

Post by louislang »

jerpint wrote: post #175
louislang wrote: post #145

Earlier quoted context omitted.

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.

Oh absolutely. Unless everyone wants to be cool and stop publishing malware, gotta take a defense in depth approach here.

Re: Dozens of malicious PyPI packages discovered targeting developers

#194

Post by erustemi »

rileymat2 wrote: post #178
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?

Maybe the issue was with how powerful and unrestricted reflection was in java before introduction of modules.

Re: Dozens of malicious PyPI packages discovered targeting developers

#195

Post by 7373737373 »

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.

Re: Dozens of malicious PyPI packages discovered targeting developers

#196

Post by peteatphylum »

heleninboodler wrote: post #170
Scarblac wrote: post #160

Earlier quoted context omitted.

That's one thing, the other is the almost complete absence of a standard library.

Yeah, I think this is a big one. One of the things that I have always liked about Golang is that the standard library is quite complete and the implementations of things are (usually) not bare-bones implementations that you need to immediately replace with something "prod-ready" when you build a real project. There are exceptions, of course, but I think it's very telling that most of my teammates go so long without i…

Totally agree. It feels like there is a pretty strong inverse correlation between standard library size, and average depth of a dependency tree for projects in a given language. In our world, that is pretty close to attack surface.

Re: Dozens of malicious PyPI packages discovered targeting developers

#197

Post by nijave »

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 saw a similar proposal (I think with JavaScript/node) not too long ago that deacribed limiting packages to data in their own namespace. For instance third-party-dep-a would only have access to data it created or was passed in versus indiscriminately accessing anything in the language VM. Even this would be a good step in the right direction although you'd likely still need something like you e described for accessing shared system resources (aka the mobile phone security model)

Re: Dozens of malicious PyPI packages discovered targeting developers

#198

Post by Legogris »

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…

For JS, You are basically talking about Lavamoat. It provides tooling and policies for SES, which aims to make it into standards.

https://github.com/LavaMoat/LavaMoat

https://github.com/endojs/endo/tree/master/packages/ses

Re: Dozens of malicious PyPI packages discovered targeting developers

#199

Post by dane-pgp »

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?

Presumably it's to trick whitehats into tipping off the hackers that their code was being analysed and had been successfully deobfuscated, so the hackers knew they needed to move to a different attack.

It's actually quite devious, like a reverse honeypot that the bad guys use against the good guys, exploiting their empathy.

Re: Dozens of malicious PyPI packages discovered targeting developers

#200

Post by dheera »

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 should be able to coexist in the SAME environment and "see" exactly the numpy versions they requested.

For python we should think about how to support something like this in the future:

    import numpy==1.15
and have it just work.

That way if a hacker compromises PyPI and releases a malicious numpy 1.19 it won't get pulled in accidentally.

Here's a bit of a joke I made before that might be an interesting starting point, though since it uses virtualenv behind the hood it doesn't have a way for multiple versions of one package to exist. I don't think it's impossible to do though with some additional work.

https://github.com/dheera/magicimport.py

Sample code:

    from magicimport import magicimport
    tornado = magicimport("tornado", version = "4.5")
Post reply on HN