louislang

Hashing solves one side of the coin. Namely, whether or not you got the thing you expected (or perhaps, got the thing you expected from the individual you expected it to come from).

On the other side, we have to contend with the fact that malware can be slipped into otherwise legitimate packages. This has happened numerous times over the years. In this case, the hash would serve as a way to say "yup, you definitely got malware". Useful for incident response, but I think we can do better and try and prevent these attacks from being viable in the first place.

This is really cool work! Also a fan of Grapl.

Phylum's extension framework is built on Deno for this exact reason. The ability to provide granular permissions was something we were really interested in.

Deno is a really cool project, imo.

This is one of the projects we're working on (and open sourcing)!

Currently allows you to specify allowed resources during the package installation in a way very similar to what you've outlined [1].

The sandbox itself lives here [2] and can be integrated into other projects.

1. https://github.com/phylum-dev/cli/blob/main/extensions/npm/P...

2. https://github.com/phylum-dev/birdcage

npm does something similar with their scoped packages. It fixes the problem for the top level packages, but you'd still have to contend with the transitive dependencies written by smaller organizations or individual contributors. In this case, you have to guarantee that no one involved in the dependency chain ever typos anything.

The problem is large, sprawling and complex. In an ideal case, we'd have high quality packages maintained by reputable people/organizations. But today this just isn't true. Open source takes contributions from a large number of unknown authors/contributors with motivations that may or might night align with your own.

We really need a defense in depth approach here. Sandbox where it makes sense, perform analysis of code being published, consider author reputation, etc.

A lot of the malware targeting developers is leveraging the installation hooks as the execution mechanism. So sandboxing the install helps stop this particular attack vector - which is why it gets talked about so much.

If you put code in the package itself, this would side step the "installation" sandbox. However we're also doing analysis of all packages introduced to the ecosystem to uncover things that are hiding in the packages themselves.

So you're right, we need a defense in depth approach here.

It's totally happening. We've seen packages targeting a lot of the big exchanges. Most of the packages are targeting developers directly though; attempting to exfil the users wallets/keys.

It definitely does help. We've seen malicious actors introduce "bad things" into legitimate packages [1]. So hashes help identify what you got, but doesn't necessarily prevent you from getting something you didn't intend.

[1] https://www.cisa.gov/uscert/ncas/current-activity/2021/10/22...

> I think the better solution is transparent sandboxing for dev environments.

I don't disagree at all. We're building an open source sandbox for devs right now for this exact reason. Linked it in another comment.

Exactly, I don't think you can rely on a naïve import to determine maliciousness. We've basically had to build out heuristics that are capable of walking function calls for this exact reason. Otherwise things are just too noisy.

I'm honestly not sure the benefits of executing code during compilation/install outweigh the bad. Most attacks we have seen leverage this as the attack vector.

They are trying. The level of effort to release these things is so low, the effort required to catch it and remove it at scale is much harder, unfortunately.

Yes, this works really well. But as soon as you deploy it, the actors change tactics. We've had to build a defense in depth approach to discovering malicious packages as they are introduced into the system.

Full disclosure, I am a co-founder at Phylum.

We are actively working on a solution that will fully sandbox package installations for npm, yarn, poetry and others.

It's rolled up as part of our core CLI [1], but is totally open source [2]:

[1] https://github.com/phylum-dev/cli [2] https://github.com/phylum-dev/birdcage

It's a slew of checks for passwords and other things on the developers machine. The data is extracted and sent to a remote endpoint controlled by the attacker.

> Yeah a time/activity based trust system like thepiratebay uses could be helpful.

This is an excellent idea. Authors are something we are digging into heavily as part of an ongoing effort to improve trust in the open source ecosystem.

For what it's worth, this happens in pretty much all the ecosystems. We have seen similar behavior in NPM, rubygems, and others. PyPI is just really popular.

That's correct, it's exfiltrating data from the developer machine

Phylum | 100% Remote | Full-time | Senior Software Engineer | https://phylum.io

Phylum is a venture backed cyber security company focusing on securing the software supply chain. We focus on the analysis of open source packages, making determinations about their risk level (e.g. does ua-parser-js contain malware?). We are seeking senior software engineers with Rust experience (although professional Rust experience is not required!) to help improve our processing pipelines, expand language support, work on our static analysis capabilities, and to help write heuristics/analytics we can run across open source ecosystems.

* $130-150k depending on experience

* Meaningful stock options

* Medical/dental/vision 100% covered by Phylum

* 3% contribution to 401k whether you participate or not

* Unlimited PTO

Tech Stack: Rust, Python, Scala, Kubernetes, Docker, Kafka

Apply https://jobs.lever.co/phylum or directly by email at careers@phylum.io

This is covered quite well in "Honeybee Democracy" by Seeley. Absolutely fascinating read about swarm intelligence.

I suspect you're probably right to be apprehensive, but it's a slight step forward from a few months back when they were signaling that a bill wasn't necessary. Progress, I guess?

Does this take registration times into account? Seems like it'd be particularly relevant in determining if this is a typosquat or not.

Docker request limits are kind of a pain to deal with in Github Actions. This recently bit us, and no amount of logging into a _paid_ docker account would rectify the problem.

As it turns out, images are pulled at the start of the run, which means your docker login will have no effect if you're currently bumping into these pull limits. This is made worse by the fact that the images themselves are controlled in the remote actions you're using, not something in your own codebase.

So you're left with either: forking the action and controlling it yourself, or hoping the maintainer will push to the Github registry.