Congratulations to Rust for its first (but not its last) supply-chain attack this week! They join a growing club of broken-by-design package managers which publish packages uploaded by vendors directly, with no review step, and ship those packages directly to users with no further scrutiny.
Timeline of major incidents on npm/Crates/PyPI/etc
- 2022-05-10: Cargo: rustdecimal ships with malicious code
- 2022-05-09: npm: foreach is taken over via an expired email domain
- 2022-03-17: npm: node-ipc ships malware targeting Russia and Belarus
- 2022-01-09: npm: colors and faker are deliberately sabotaged
- 2021-11-19: PyPI: 11 malicious packages discovered
- 2021-11-04: npm: rc ships malicious code
- 2021-11-04: npm: coa steals your passwords
- 2021-10-22: npm: ua-parser-js ships malicious code
- 2021-10-11: PyPI: mitmproxy2 typo-squats mitmproxy with an added RCE
- 2021-07-30: PyPI: 8 malicious packages discovered
- 2020-12-16: RubyGems: pretty_color (and one other) steals bitcoin from victims
- 2020-09-11: npm: dozens of packages steal your user’s credit card number
- 2020-09-03: npm: bb-builder steals your password
- 2020-04-16: RubyGems: 760+ malicious packages found stealing bitcoin
- 2018-11-28: npm: event-stream ships with a bitcoin theft kit
- 2018-10-21: PyPI: colourama sneaks bitcoin addresses into your clipboard
- 2018-10-13: PyPI: more typo-squatting malware attempts various attacks
- 2018-07-12: npm: eslint-scope ships with malicious code
- 2018-07-08: AUR: acroread is compromised
- 2018-05-11: Snap: a 2048 clone ships a cryptocurrency miner
- 2017-09-09: PyPI: typo-squatted packages published by researchers
- 2016-07-22: npm: left-pad incident
There are hundreds of additional examples. I had to leave many of them out. Here’s a good source if you want to find more.
Timeline of similar incidents in official Linux distribution repositories
Why is this happening?
The correct way to ship packages is with your distribution’s package manager. These have a separate review step, completely side-stepping typo-squatting, establishing a long-term relationship of trust between the vendor and the distribution packagers, and providing a dispassionate third-party to act as an intermediary between users and vendors. Furthermore, they offer stable distributions which can be relied upon for an extended period of time, provide cohesive whole-system integration testing, and unified patch distribution and CVE notifications for your entire system.
For more details, see my previous post, Developers: Let distros do their job.
Can these package managers do it better?
I generally feel that overlay package managers (a term I just made up for npm et al) are redundant. However, you may feel otherwise, and wonder what they could do better to avoid these problems.
It’s simple: they should organize themselves more like a system package manager.
- Establish package maintainers independent of the vendors
- Establish a review process for package updates
There’s many innovations that system package managers have been working on which overlay package managers could stand to learn from as well, such as:
- Universal package signatures and verification
- Reproducible builds
- Mirrored package distribution
For my part, I’ll stick to the system package manager. But if you think that the overlay package manager can do it better: prove it.