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

301–310 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#301

Post by fsflover »

namaria wrote: post #63
kibwen wrote: post #56

Earlier quoted context omitted.

This is a good approach, though presumably the VM still has access to your Github credentials (via the browser) and your SSH keys? It'll limit the fallout of getting owned to anything reachable from Github (is it against Github's TOS to have multiple accounts?), less if you have 2FA (does there exist 2FA for SSH keys (I don't mean passphrases)?), but I think it would be better for just my build/run/test cycles to be…

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.

Why wouldn't you use disposable VMs [0] and secure inter-VM copy [1] on Qubes OS instead? It's much less cumbersome and more secure.

[0] https://www.qubes-os.org/doc/how-to-use-disposables/

[1] https://www.qubes-os.org/doc/how-to-copy-and-move-files/

Re: Dozens of malicious PyPI packages discovered targeting developers

#302

Post by rollcat »

CoolCold wrote: post #299
paulmd wrote: post #277

Earlier quoted context omitted.

Same for FreeBSD. Incredibly code-stable and well-documented by Linux standards. I often use the FreeBSD Handbook as an example of first-party documentation done right, and that's only possible because of deliberately limited "churn for churn's sake". The kinds of regular code rot and attrition that Linux suffers just does not take place on BSD systems because if you contribute something new you're expected to make y…

And with all that beauty, FreeBSD is not something I would [nowdays] look into as base OS for hosting my services and products. It means something, probably something about humans.

Netflix uses FreeBSD for their CDN/edge caches - it was consistently more performant both in benchmarks and with real-world workloads.

Re: Dozens of malicious PyPI packages discovered targeting developers

#303

Post by Beltalowda »

yakubin wrote: post #288
Beltalowda wrote: post #279

Earlier quoted context omitted.

You should have the modules downloaded to the module cache for the occasional case when you don't have direct internet access. > Another case: repo of your dependency is removed, or force-pushed to overwriting history. You’ve lost the ability to build your project, and need to either find another source for your dependency, or rewrite it. The GOPROXY ( https://proxy.golang.org/ ) still contains that removed repo, and…

> You should have the modules downloaded to the module cache for the occasional case when you don't have direct internet access. That’s assuming I’ve built the thing previously on that same computer. I’m talking about the common case of working on a normal desktop day-to-day and then switching to a laptop, when travelling to a place without internet (or internet of such a poor quality you might as well not bother). W…

You need internet access to either checkout or update the repo; you can use "go mod download" (or just go build, test, etc.) to fetch the modules too. It's an extra step, but so is vendoring stuff all the time.

But like I said, it's not about "is it useful in some scenarios?" but "is it worth the extra effort?" I'm a big fan of having things be self-contained as possible but for this kind of thing modules "just work" without any effort. Very occasionally you might go "gosh, I wish I had vendored things!", but I think that's an acceptable trade-off.

Re: Dozens of malicious PyPI packages discovered targeting developers

#304

Post by int_19h »

nl wrote: post #201
insanitybit wrote: post #185

Earlier quoted context omitted.

Part of the problem with the Java sandbox is that it was enforced entirely by the VM + the VM is written in C++. The idea is not inherently bad.

It's been a while since I worked in this area but my recollection was that most JVM security issues in this areas were bypasses of the Java Security Manager often by confusing it about code origin. That's all Java code, not C++.

For both Java and .NET, there were actual verification bugs, as well - when bytecode that's not supposed to be valid gets past the verifier and results in e.g. mistyped references (which can then be used for all kinds of creative vtable abuse). Sometimes it can even be a bug in the VM spec itself, because implications of two different features interacting weren't fully considered.

But, yes, we've tried this idea many times now, and it never held up for long.

Re: Dozens of malicious PyPI packages discovered targeting developers

#305

Post by HeavyStorm »

A good strategy would be to not allow typosquatting by just blocking names that too similar (something simple as hamming distance would suffice here).

Afaik there are two types of supply chain attacks strategy - you either compromise the a legitimate package by somehow getting a PR approved with malicious code, which is very hard to do, or you "typosquat". The latter is way easier and probably the dominant strategy, so package repositories such as PiPy need to invest into preventing it.

Edit: formatting, grammar

Re: Dozens of malicious PyPI packages discovered targeting developers

#306

Post by nirimda »

FractalHQ wrote: post #256
ryukafalz wrote: post #248

Earlier quoted context omitted.

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

If you want to override the dependency of your dependency, then it's your dependency too - so if you were using the javascript approach up there you might have

    var bar = require("bar", {baz: loggingBaz})
    var foo = require("foo", {bar})
This is true even if you never otherwise use bar.

This is certainly how peer dependencies work in nix flakes, for instance, where you can say something like

   bar = //....
   bar.inputs.baz.follows = loggingBaz;
   foo = //....
   foo.inputs.bar.follows = bar;
Since nix flakes is a package/dependency manager, it generates a lockfile that you could inspect too see what all the dependencies are, and make sure you got it right (oh, I still have two bar's, I must have forgotten to override some other dep). I suppose any compiler that involves a linking stage would in principle be able to generate some comparable output at the language level.

(Apologies for using require and var, but I'm convinced the functional syntax is semantically clearer in this context.)

Re: Dozens of malicious PyPI packages discovered targeting developers

#308

Post by berkes »

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.

Ive contracted on a project where another, IMO better, solution was employed. This was ruby.

The only allowed package (gem) server was one ran by the project. This package-server scanned, vetted and manually checked any version of a lib before "publishing it".

If you wanted to e.g. upgrade a package, you'd have to do this on this server first. It would then go through some steps, -automatic scanning, risk analysis, sometimes even needing the eyes of someone from a security team. After that the package was published on this server, and you could pull it onto your dev machine and use it in CI/staging/test/prod etc. Similar steps, to get a new package listed.

IMO this is better, because it stops supply-chain attacks before they hit your code, not after they've (potentially) infected the system.

Edit: for clarity "only allowed package" wasn't enforced very strictly. A linter and CI would catch any changes to code that would want to fetch packages from elsewhere. It wasn't to protect against rogue developers, but against "stupid me, accidentally upgrading to a version that is infected" and such.

Re: Dozens of malicious PyPI packages discovered targeting developers

#309

Post by berkes »

HeavyStorm wrote: post #305

A good strategy would be to not allow typosquatting by just blocking names that too similar (something simple as hamming distance would suffice here). Afaik there are two types of supply chain attacks strategy - you either compromise the a legitimate package by somehow getting a PR approved with malicious code, which is very hard to do, or you "typosquat". The latter is way easier and probably the dominant strategy,…

A third is to fill a niche. E.g. if there's no "storage library for DigitalOcean Block Storage"[1], one can make it and publish it[2]. It would work as advertised, but maybe do some additional stuff, like sending the API keys to malicious server too. Unknowing developers would be searching, seeing something that promises to solve their problem, and use that.

I haven't encountered this in the wild yet, but IMO it's reasonably easy. More work than typosquatting, for sure, but probably less work than getting a malicious PR accepted in an existing project.

[1] It's just an example, doesn't exist, and if (by now) it does, I never meant to hint it is malicious. DO is just an example, and I have nothing but good to say about their services (and libraries) where they exist.

[2] The example here would be to just copy the S3 library, because DO block storage is fully compatible with S3 API. Which would also be the reason a dedicated library doesn't need to exist.

Re: Dozens of malicious PyPI packages discovered targeting developers

#310

Post by mrlemke »

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 thought of OpenBSD too since it includes Perl modules for OpenBSD::Pledge and OpenBSD::Unveil. Now I'm wondering if I can get something to work where these are used before importing CPAN modules to reduce the damage of potentially hostile modules.
Post reply on HN