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

Re: Dozens of malicious PyPI packages discovered targeting developers

#331

Post by jononor » Fri, Nov 04, 2022, 8:32 PM UTC

bernawil wrote: post #259

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…

A resource access model for dependencies doesn't make much sense to me, there's basically only 2 things you want to gate access for libraries: filesystem and network. And it's all-in. A library that needs network access may be legit today and after an update start exfiltrating data to a different url. It seems easier to grep for fs and network calls in the library code than any of that.

Restricting a process to only be able to access opt-in list of directories underneath the project directory would be useful. Assuming one uses a venv, and all the dependencies are contained there. Then one might want some data folder. And have at least prevented dels from scraping user-wide secrets.

Re: Dozens of malicious PyPI packages discovered targeting developers

#332

Post by bernawil » Sat, Nov 05, 2022, 4:13 AM UTC

jononor wrote: post #331

bernawil wrote: post #259

Earlier quoted context omitted.

A resource access model for dependencies doesn't make much sense to me, there's basically only 2 things you want to gate access for libraries: filesystem and network. And it's all-in. A library that needs network access may be legit today and after an update start exfiltrating data to a different url. It seems easier to grep for fs and network calls in the library code than any of that.

Restricting a process to only be able to access opt-in list of directories underneath the project directory would be useful. Assuming one uses a venv, and all the dependencies are contained there. Then one might want some data folder. And have at least prevented dels from scraping user-wide secrets.

You're describing a chroot jail. key there is "process". Dealing with processes permissions is the OS's job.

A if a language wants to deal in library's security it should strive to make static analysis possible. Eg: the language guarantees that network and filesystem calls can only be done with a single function, statically so I can audit that leftpad indeed doesn't make network calls .

Re: Dozens of malicious PyPI packages discovered targeting developers

#333

Post by chlorion » Mon, Nov 07, 2022, 12:16 AM UTC

Quentak wrote: post #268

chlorion wrote: post #241

Earlier quoted context omitted.

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

How do you escape the sandbox through a Wayland or X11 socket? Do you have specific code examples? Is there no way to safely run graphical applications in a bwrap sandbox? I thought Wayland was supposed to be better about this.

I do not have a specific code example, but you can use the normal X11 client interfaces to interact with the X server, which allows a lot of dangerous things such as sending events to other clients. We can imagine a rouge X11 client spawning a terminal and entering text through a virtual input interface, to run an arbitrary command for example.

On Wayland, assuming you don't have XWayland enabled and running, it depends on the specific compositor you are using and what Wayland protocols it supports.

Sandboxing GUI stuff on Wayland requires at the very least not having XWayland running, and also requires understanding what the compositor allows clients to do by default. Some compositors may have permission dialogues that prevent clients from doing stuff that you didn't expect.

Re: Dozens of malicious PyPI packages discovered targeting developers

#334

Post by imawasp » Wed, Nov 09, 2022, 2:22 PM UTC

neurostimulant wrote: post #130

remram wrote: post #123

Earlier quoted context omitted.

Couldn't you use someone else's IRC server, the same way you use Discord's server?

I suppose you could, but have you seen how popular new opensource projets being run these days? Young devs really loves discord to the point of hosting documentations there. I imagine young malware authors are no different.

No post body was provided.