3 ms·
Yep, supply chain attacks are a near-universal problem with programing language package managers. I think there's a lot of room for improvement here. Some good
by Ajedi32 5y ago
Yep, supply chain attacks are a near-universal problem with programing language package managers.
I think there's a lot of room for improvement here. Some good low-hanging fruit IMO would be to:
1. Take steps to make package source code easier to review.
1.1. When applicable, encourage verified builds to ensure package source matches the uploaded package.
1.2. Display the source code on the package manager website, and display a warning next to any links to external source repositories when it can't be verified that the package's source matches what's in that repo.
1.3. Build systems for crowdsourcing review of package source code. Even if I don't trust the package author, if someone I _do_ trust has already reviewed the code then it's probably okay to install.
2. Make package managers expose more information about who exactly you're trusting when you choose to install a particular package.
2.1. List any new authors you're adding to your dependency chain when you install a package.
2.2. Warn when package ownership changes (e.g. new version is signed by a different author than the old one).
Long-term, maybe some kind of sandbox for dependencies could make sense. Lots of dependencies don't need disk or network access. Denying them that would certainly limit the amount of damage they can do if they are compromised, provided the host language makes that level of isolation feasible.
- _tom_ 5y agoAnalysis tools that show where large transitive dependencies could be avoided would help. Right now there is no feedback to encourage people to not have HUGE lists of dependencies. And for trivial reasons. This compounds the problem hugely. If you have three dependencies, verifying is feasible. If you have 3,000, it is not.
- ansible 5y agoI like all these ideas. > Long-term, maybe some kind of sandbox for dependencies could make sense. Lots of dependencies don't need disk or network access. Just like with Android permissions, we could audit the crate sources to list out what functions it uses (out of the standard library or where ever) and provide an indication of that this particular crate is capable of.
- UncleMeat 5y agoThis is a strategy, but it typically falls apart against clever attackers who are targeting you specifically. Hackers have been performing return-to-libc attacks forever where they don't actually get to write any code at all, just sequence code that already exists in your binary. Java also tried this in a slightly more rigorous manner with the SecurityManager and that just ended up being a botch.
- Ajedi32 5y agoYeah that's why I said it really depends on the host language to make such sandboxing feasible. If you're using a language that lets code write arbitrary data to arbitrary memory locations, implementing a secure sandbox is going to be pretty tricky.
- dane-pgp 5y agoFor what it's worth, this Principle Of Least Authority / object-capability model is being attempted in the JavaScript ecosystem with SES (Secure ECMAScript). https://agoric.com/blog/technology/ses-securing-javascript/ https://agoric.com/blog/technology/ses-securing-javascript/ https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...