Dozens of malicious PyPI packages discovered targeting developers • Hacker News Board

Re: Dozens of malicious PyPI packages discovered targeting developers

#321

Post by tornato7 » Thu, Nov 03, 2022, 6:45 PM UTC

heleninboodler wrote: post #164

augusto-moura wrote: post #159

Earlier quoted context omitted.

The problem is the tree of dependencies you might check. Sure you can check the changes in a direct dependency, but when that dependency updates a few others and those update a few others, the number of lines you need to read grow very quickly

Golang flattens the entire dependency tree into your vendor directory. It's still not that big. The current project I am working on has 3 direct external dependencies, which expands out into 22 total dependencies, 9 of which are golang.org/x packages (high level of scrutiny/trust). It's really quite manageable.

Indeed, gophers often make it a point of pride to have no dependencies in their packages.

Re: Dozens of malicious PyPI packages discovered targeting developers

#322

Post by 7373737373 » Thu, Nov 03, 2022, 8:17 PM UTC

actually_a_dog wrote: post #320

7373737373 wrote: post #184

Earlier quoted context omitted.

If you actually have to execute a program (but have no safe way of doing so), to see if a complex routine that may return any filename imports a safe file or not, then you are facing up against https://en.wikipedia.org/wiki/Rice%27s_theorem

So? Any method of detecting a "malicious package" faces Rice's theorem, unless you want to claim that "malicious" is a trivial property.

Which is why any approaches relying on identity verification or scanning are bound to fail - sandboxing/capability security MUST become built into languages

Re: Dozens of malicious PyPI packages discovered targeting developers

#323

Post by CoolCold » Fri, Nov 04, 2022, 8:14 AM UTC

rollcat wrote: post #302

CoolCold wrote: post #299

Earlier quoted context omitted.

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.

Yeah, that's quite interesting reading from them, some sort of specialized appliance really.

I'm and the average Joe around me, totally far from Netflix's task of packing bytes from disk to network. Simple 2vCPU VPS serving 4GBit without being saturated on system resource level is quite often much more than enough. Extra note - it's not even using kTLS.

Moreover, even for Netflix, noting they know FreeBSD in and out, do you think/have info on using FreeBSD as base OS beyond distribution level - running applications/services in particular?

I've quickly checked on their repos like https://github.com/Netflix/conductor and it smells like they use containers/Docker, which doesn't work on FreeBSD => I'm in very much doubts it's OS of choice for them.

Re: Dozens of malicious PyPI packages discovered targeting developers

#324

Post by Riverheart » Fri, Nov 04, 2022, 12:29 PM UTC

jve wrote: post #209

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…

Github offers fine grained personal access tokens. https://docs.github.com/en/authentication/keeping-your-accou... Azure DevOps does it too

Far as I know, in AzDO you can't even limit a PAT to a single project/repository. Not good for limiting access cause even a read only can see private stuff in other projects. You might create a specific account and assign to only that project but what a pain.

Re: Dozens of malicious PyPI packages discovered targeting developers

#325

Post by Riverheart » Fri, Nov 04, 2022, 12:54 PM UTC

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

Curation. Have a wide open repo and then have a repo of curated packages. There is no typo squatting in the curated repo because a human had to approve it.

Pip install ansible --from curated.pypi.org

Pip install anssible --from wildwest.pypi.org

Let them typosquat all they want in the wildwest. I don't worry about this nonsense with Apt. Heck maybe curation becomes a revenue stream to pay to get in to support such activites.

Re: Dozens of malicious PyPI packages discovered targeting developers

#326

Post by ashishbijlani » Fri, Nov 04, 2022, 2:29 PM UTC

7373737373 wrote: post #322

actually_a_dog wrote: post #320

Earlier quoted context omitted.

So? Any method of detecting a "malicious package" faces Rice's theorem, unless you want to claim that "malicious" is a trivial property.

Which is why any approaches relying on identity verification or scanning are bound to fail - sandboxing/capability security MUST become built into languages

Are you suggesting that you would rather wait for languages to provide robust sandboxing capabilities and not use available static/dynamic analysis tools (e.g., Packj [1]) to audit packages for malicious/risky indicators, particularly when we hear about new attacks on open-source package managers almost every week?

1. https://github.com/ossillate-inc/packj [Disclaimer: I built it]

Re: Dozens of malicious PyPI packages discovered targeting developers

#327

Post by ashishbijlani » Fri, Nov 04, 2022, 3:05 PM UTC

pabs3 wrote: post #296

Are any tools to detect such malicious modules, or are PyPI reliant on proprietary services by third parties to do that?

I built Packj to flag such "risky" packages: https://github.com/ossillate-inc/packj

Re: Dozens of malicious PyPI packages discovered targeting developers

#328

Post by pxc » Fri, Nov 04, 2022, 4:33 PM UTC

john61 wrote: post #48

This is one reason I prefer Debian python packages.

This is definitely a benefit of using distro-provided packages.

You get some vetting, and in addition, standard practice for many distros is to build everything that goes into the repos in sandboxes or VMs which have restricted or no network access. Additionally, some package managers incorporate that kind of sandboxing into their builds categorically, like Nix and Guix. (For Nix, this may only be on Linux— there are issues with sandboxing on macOS.) So if you build your project's dependencies via Nix or Guix, you're also protected.

This only protects you from `setup.py`-type (build time) attacks, of course. If the distro packages get compromised in some other way so that malicious code ends up in your installed programs (this attack has elements of that, IIRC), you're still in trouble.

Re: Dozens of malicious PyPI packages discovered targeting developers

#329

Post by 7373737373 » Fri, Nov 04, 2022, 7:14 PM UTC

ashishbijlani wrote: post #326

7373737373 wrote: post #322

Earlier quoted context omitted.

Which is why any approaches relying on identity verification or scanning are bound to fail - sandboxing/capability security MUST become built into languages

Are you suggesting that you would rather wait for languages to provide robust sandboxing capabilities and not use available static/dynamic analysis tools (e.g., Packj [1]) to audit packages for malicious/risky indicators, particularly when we hear about new attacks on open-source package managers almost every week? 1. https://github.com/ossillate-inc/packj [Disclaimer: I built it]

No, I'm merely suggesting that they are not a solution to the problem, and that the fundamental issue has to be approached at the language level.

What you are building is mainly a smoke detector (and maybe a bit of a sprinkler if it takes some decisions itself), not fireproof doors (that only at install, not test- or runtime). Smoke detectors by themselves cannot prevent fires from spreading and are not completely reliable.

Analysis tools are still useful - even with perfect language-level access and resource control, packages which are given many required permissions may behave maliciously (e.g. through compromise of any component in the development or distribution pipeline), or return malicious data (which is out of scope/unsolvable at the language level). Both approaches complement each other nicely.

Re: Dozens of malicious PyPI packages discovered targeting developers

#330

Post by [deleted] » Fri, Nov 04, 2022, 7:44 PM UTC

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.

[deleted]