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

241–250 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#241

Post by chlorion »

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.

Another good option is to create a new user and run everything under the new UID. Running under a new UID has less chances of accidentally leaving something exposed that can allow for sandbox escape.

If you run everything from the new UID, it will mostly be contained to it's own $HOME directory and be unable to modify your user's files or system files. Some distros do not protect home directories from being read so it might be worth setting your actual user's $HOME to umask 0700 or whatever.

If you are using bwrap while running X11 and not running the sandbox with a new UID, the sandboxed processes may be able to escape via the X11 socket! This can happen even when you don't mount the X11 socket into the sandbox (see abstract sockets)! I think unsharing the network namespace fixes this specific issue (not 100% sure), but there are probably more subtle footguns like this.

I really suggest running Wayland with XWayland disabled, and the Wayland socket protected from the sandbox if you want to use bwrap for security purposes!

Re: Dozens of malicious PyPI packages discovered targeting developers

#242

Post by chlorion »

iudqnolq wrote: post #85
WalterBright wrote: post #74

Earlier quoted context omitted.

It means you don't need to run the compiler in a sandbox. People do not expect the compiler to be susceptible to malware attacks, and I do what I can to live up to that trust. I haven't heard of anyone creating a malicious source file that would take advantage of a compiler bug to insert malware, but there have been a lot of such attacks on other unsuspecting programs, like those zip bomb files.

> People do not expect the compiler to be susceptible to malware attacks I'm not familiar with D, so I'll use the example of Rust. My usual workflow looks something like this 1. Make some changes 2. Either use `cargo test` to run my tests or `cargo run` to run my binary. In both those cases the code is first compiled and subsequently run. I care if running that command gives me malware. I don't care at what step it h…

Some people try to inspect code outside of a project before including it into something.

Say there is a Github repo with a crate called "totally_safe_crate", and I want to use this crate in my project, but I am not sure whether I can trust it or not. What do I do?

What I would likely do is clone the repo, then open my editor and look through the source and whatnot and make my decision.

In this case I never intend to run "cargo run" at all, but I may want to run an LSP server to help inspect the code, or I may accidentally enable LSP in the editor out of habit or something.

In this case, it would be nice if I could be certain that simply inspecting and reading code was safe, but as it stands now, in Rust, this is not the case. We can't even inspect code to make sure it's safe unless we open the source files in a "dumb" editor.

In your example you are just adding a crate to cargo.toml and firing off cargo, so of course it's not going to be useful there. Some of us may want to be more cautious than that and actually read code before putting it in our projects.

Re: Dozens of malicious PyPI packages discovered targeting developers

#243

Post by sedatk »

nine_k wrote: post #240
YetAnotherNick wrote: post #157

Earlier quoted context omitted.

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

What if the package is signed by a key available at google.com/pypi/key ? Actually it should be not just a key but a whole TLS certificate, with references to a CA, activity dates, etc.

How would you know where you’d find that key?

Re: Dozens of malicious PyPI packages discovered targeting developers

#244

Post by galangalalgol »

peteatphylum wrote: post #196
heleninboodler wrote: post #170

Earlier quoted context omitted.

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.

Rust is another example of this. Just bringing in grpc and protobuf gets about a hundred dependencies. Some of them seemingly unrelated. For a language aimed at avoiding security bugs, I find this to be an issue. But a good dependency manager and a small (or optionally absent) stdlib has lead to highly granular dependencies and bringing in giant libs for tiny bits.

Re: Dozens of malicious PyPI packages discovered targeting developers

#245

Post by amelius »

LudwigNagasena wrote: post #8
lupire wrote: post #6

Open/free software is great when a great person writes some code and lets you use it, because they are kind and there's nearly no marginal cost. But malicious actors can get value from polluting the sharing network, and that costs effort to defend against, which means someone(s) has to pay to secure the network, or be open to attack.

That’s not an either or thing. Someone you pay to can also be a malicious actor.

Yes and it is common too. E.g. the vendor of my SmartTV now has a probe in my home.

Re: Dozens of malicious PyPI packages discovered targeting developers

#246

Post by 0xblinq »

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…

Wouldn't running your development environment inside docker provide the same safety levels?

Re: Dozens of malicious PyPI packages discovered targeting developers

#247

Post by panny »

n4bz0r wrote: post #131
sc__ wrote: post #21

The article doesn't explain what exactly the "W4SP Stealer" does. Would someone be able to explain?

The source is actually hosted on GitHub, and there is a good readme explaining all that :) https://github.com/loTus04/W4SP-Stealer

If I hosted malware, I would be in jail. It is against the law. I wonder why Github is allowed to host malware, and continues to provide a platform for it?

https://sanctiontrace.com/malware-hosting-providers-sentence...

Re: Dozens of malicious PyPI packages discovered targeting developers

#248

Post by ryukafalz »

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 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 = require('stringutils');
That way, you can pass in at a very fine-grained level any object you want to, including things like `fetch` and `fs`. But then, you could just as easily pass in a custom `loggedFetch` module like so, that wraps `fetch` and logs all network requests made:

    const apollo = require('apollo-client', {fetch: loggedFetch});
This is the object-capability security model, and as a sibling commenter pointed out, LavaMoat basically does this for JavaScript dependencies. (This is also basically just lexical scope, by the way, if your language is strict enough - though most unfortunately aren't.)

Re: Dozens of malicious PyPI packages discovered targeting developers

#249

Post by djbusby »

Would it be possible to make a more trusted package mirror?

Somehow validating packages before inclusion?

IIRC mirrors for NPM, Packagist and others is not impossible, can be done for PyPY and others too?

Maybe it's a stop-gap before all the fancy permissions feature build out (which seems hard)

Post reply on HN