Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious PyPI packages stealing credit cards and injecting code

jfrog.com

Post reply on HN
Print view View original

131–140 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#131

Post by hortense »

HALtheWise wrote: post #119

It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…

This can be done with capability-based operating system, though it requires running the libraries you want to isolate in a separate process.

On a capability-based OS you whitelist the things a given process can do. For instance, you can give a process the capability to read a given directory and write to a different directory, or give the capability to send http traffic to a specific URL. If you don't explicitly give those capabilities, the process can't do anything.

Re: Malicious PyPI packages stealing credit cards and injecting code

#132

Post by polynomial »

wereHamster wrote: post #66
specialist wrote: post #38

Earlier quoted context omitted.

I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…

Everyone I know uses some form of lock file, and most of the modern programming languages support it. As for upgrading only when absolutely necessary, let's be honest, nothing is absolutely necessary. If the software is old, or slow, or buggy, well dear users you'll just have to deal with it. In my experience however, it's easier to keep dependencies relatively up to date all the time, and do the occasional change th…

In my experience although lock files are widely used in Node development, utilizing the lock files as part of a reproducible build system is far less prevalent in the wild. In fact, the majority of Node development I've seen eschews reproducible builds on the basis that things are moving too fast for that anyway, as if it were somehow a DRY violation, but for CICD. Would love to hear from Node shops that have established well followed reproducible CICD.

Re: Malicious PyPI packages stealing credit cards and injecting code

#133

Post by null_deref »

fortran77 wrote: post #20
null_deref wrote: post #2

Oh at last, I can feel slightly less ashamed of being part of the Israeli technology scene.

כל ישראל ערבים זה לזה

I fully believe in this statement, and let me assure you I'm proud to be Israeli. But, when NSO articles pop like mushrooms after rain, I feel sad for a period of time (a feeling I also encounter when I read about Israeli internet gambling companies).

Re: Malicious PyPI packages stealing credit cards and injecting code

#134

Post by delosrogers »

HALtheWise wrote: post #119

It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…

If I’m not mistaken I think that some languages with managed effects allow you to do this through types. For example, in Elm HTTP requests have the type of Cmd Msg and the only way to actually have the IO get executed is to pass that Cmd Msg to the runtime through the update function. This means you can easily get visibility, enforced by the type system, into what your dependencies do and restrict dependencies from making http requests or doing other effects.

Re: Malicious PyPI packages stealing credit cards and injecting code

#135

Post by landonxjames »

HALtheWise wrote: post #119

It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…

Deno (a Node-like runtime by the original author of Node) has a security model kind of like this [0]. Its unfortunately not as granular as I think it should be (only operates on the module level and not individual dependencies), but its a start.

[0] https://deno.land/manual/getting_started/permissions

Re: Malicious PyPI packages stealing credit cards and injecting code

#136

Post by tadfisher »

parhamn wrote: post #123
HALtheWise wrote: post #119

It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…

I was wondering earlier how useful deno's all-or-nothing policies would actually be in the real world. It seems like rules like this (no dep network requests, intranet only, only these ips) are much more useful than "never talk to the web". For python this probably wont ever be possible given the way the import system works and the patching packages can do.

Portmod[0] is a package manager for game modifications (currently Morrowind and Doom), and it runs sandboxed Python scripts to install individual packages. So I think this is possible, but it's not a built-in feature of the runtime as is the case for deno.

[0]: https://gitlab.com/portmod/portmod

Re: Malicious PyPI packages stealing credit cards and injecting code

#137

Post by jameshart »

tremon wrote: post #125
pornel wrote: post #112

Earlier quoted context omitted.

Own hosting, pinning, and checksum checks are defenses against network-based attacks and compromise of the package repository. They do nothing against trojans like these. You will be running your own pinned checksummed version of the malicious code. If you want to stop malware published by the legitimate package author, you need to review the code you're pulling in and/or tightly sandbox it (and effective sandboxing…

Well, it does induce a timed delay between upstream release of a compromised package and when it enters the own codebase. As long as the exploit is found and published before someone manually uploads it to the local store, you're safe. But yes, a better option would be to run your own acceptance tests on each new upstream release, and that includes profiling disk/network/cpu usage across different releases.

Also introduces that same time delay for getting security patches released by package maintainers into your build pipeline.

Re: Malicious PyPI packages stealing credit cards and injecting code

#138

Post by helsinki »

HALtheWise wrote: post #119

It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…

This is a great idea, but I'm not sure how it could be implemented without cgroups, which are a pain, especially when you don't have root access.

Re: Malicious PyPI packages stealing credit cards and injecting code

#139

Post by zerkten »

polynomial wrote: post #130
yjftsjthsd-h wrote: post #101

Earlier quoted context omitted.

Sorry, I don't quite see how this would protect against supply chain attacks. If an upstream dependency is back-doored, they just have to silently add their code in an otherwise reasonable sounding release, and now you will happily download that version, add it to your internal mirrors, and pin its version forever. Unless you actually read the diff on every update, which I think is impractical (although you're welcom…

My read was GP is implying they do read the diff every time, and only change the pinned version after a manual review- "only after we are happy." This does seem impractical at even a modest scale.

What does "modest scale" mean? Some people have to have all dependency updates reviewed and have some level of independent security team monitoring dependency changes. Not everyone has this, but the context is key as some domains have this consistently.

Some of this is cultural in addition to being paranoid about security, or having strict compliance requirements. For your average startup, they may not have any time to dedicate to this and other fires, but that's not a universal situation.

Re: Malicious PyPI packages stealing credit cards and injecting code

#140

Post by goodpoint »

mikepurvis wrote: post #120
goodpoint wrote: post #93

Earlier quoted context omitted.

> I think the industry at large lost something in the transition. Lost a lot of trust and security with the advent of language-specific installers that pull libraries and their dependencies from random URLs without any 3rd party vetting.

I agree, though I think there are a couple pieces to the puzzle. Like, quite apart from the enormous convenience of new releases being available right away, and even being able to drop in a git URL and run your dependency off a branch while you wait for your upstream PR to merge, pip provides isolation between workspaces that apt has never been able to do natively because it's too generic— the closest thing is lightw…

> pip provides isolation between workspaces that apt has never been able to do natively because it's too generic

This is hardly a concern on production systems. It's been common practice for decades to deploy each service on a dedicated host, or at least a VM in order to have a degree of security isolation. [or a container if you don't care]

> npm, cargo, etc showed how to include a dependency multiple times at different versions

And this is why they cannot provide stable releases and security backports.

If you want security updates you can use Debian or pay $$ for SuSE or Red Hat or $$$$ for custom support from some tech companies, but they will mostly support one version per package.

The combinatorics explosion of packages times versions on archives like npm or pypi makes it prohibitively expensive to reliably patch and test every combination of packages and versions.

Debian has been pioneering reproducible builds and automated installation CI/QA and it still took a lot of effort to get there.

> I don't think the system you want (isolation, version freedom, but with safe/vetted packages) is going to be something that's possible to evolve out of any of the current systems.

I don't want version freedom: it's not attainable. It's not a software problem, it's a math problem.

> It's got to be something that goes back to first principles.

Any idea?

Post reply on HN