|
JavaScript has quickly become the most popular development language of all time, and along with it, new practices in software engineering. Developers rely on third-party packages from a service called 'npm' to solve common problems, helping avoid reinventing the wheel over and over.
Many of these packages are open source, which makes them free and easy to use, but often developers don't even know who's responsible for maintaining it. This week, a package relied on by millions of applications was discovered to be quietly compromised, targeting businesses that blindly relied on it.
The package, called 'Event Stream' was technically abandoned by its owner a while ago, but recently adopted and transferred to an anonymous new owner who had made many legitimate contributions. The new owner maintained it for a while, then started quietly adding new, encrypted dependencies to the package, designed to compromise applications on a fundamental level.
What happened next was amazing: a user raised the flag in a GitHub issue, saying that they had discovered a mysterious attack and scrambling to understand what it actually did. It turns out that the malicious code was designed specifically to steal access keys from digital currency wallets that rely on the library, exposing users unknowingly.
The implications of this attack are wild: the open source community largely relies on trust, and very few developers review the packages they install outside of large-scale enterprises. This attack was disguised is plain sight, and demonstrates how simple it is to compromise millions of people unwittingly.
Who's at fault, then? I'd argue the problem here isn't with the original developer of the library, but two systematic issues: first, that businesses of all sizes rely on open source software without paying for its maintenance, leading to the ultimate outcome here. Second, we all expect these libraries to exist without much thought as to who's looking after them in the first place.
Open source, despite all of these years in existence, still hasn't figured out a business model. If developers of projects offered support contracts or even simply invoices for larger companies, they'd certainly consider paying to guarantee the existence of these projects long-term.
Worse still, it's impossible to actually vet these tools at scale. NPM, the package manager where developers install libraries from, doesn't have a way to gauge whether or not a project is maintained. Nor does it offer those software developers a way to monetize their projects and make it clear that they need funds or assistance to maintain them.
This isn't the first time the library-focused perils of modern JavaScript have reared their head: in 2016, a developer broke thousands of web applications by pulling his libraries as a part of a copyright spat. This time was the first at-scale malicious threat we've seen, but I don't think it will be the last, either.
Do we need an antivirus scanner for package libraries? Or a way to judge which ones can be trusted? Like always, the internet remains the wild west, but what matters most is collectively finding a better way to build these systems to prevent this kind of abuse.
🌎 Hacker back-doors widely-used software (Ars Technica)
|
