Malicious javascript compromise on npmjs.com
These packages, about a billion downloads prior
supports-hyperlinks
chalk-template
simple-swizzle
slice-ansi
error-ex
is-arrayish
wrap-ansi
backslash
color-string
color-convert
color
color-name
Thread follows.
A bunch of packages published by qix in NPM just got backdoored it looks like. Obfuscated code was added like two hours ago. #threatintel #npm
If you want an idea of scale of trojan attempt - 'color' alone had 32m downloads in a week, the combined attempt was pushing a billion due to upstream dependencies.
Hunt tip: look for registry.npmjs.org in proxy logs, package names are in the URLs.
additional backdoored packages
ansi-styles
debug
chalk
supports-color
strip-ansi
ansi-regex
has-ansi
Weekly download stats for impacted packages prior to incident
ansi-styles (371.41m)
debug (357.6m)
backslash (0.26m)
chalk-template (3.9m)
supports-hyperlinks (19.2m)
has-ansi (12.1m)
simple-swizzle (26.26m)
color-string (27.48m)
error-ex (47.17m)
color-name (191.71m)
is-arrayish (73.8m)
slice-ansi (59.8m)
color-convert (193.5m)
wrap-ansi (197.99m)
ansi-regex (243.64m)
supports-color (287.1m)
strip-ansi (261.17m)
chalk (299.99m)
Total 2674m
@leoluk @GossiTheDog Draconian systems that limit who can write and publish code are NOT the solution here.
The solution is not having LPMs (language package managers) that pull code from unvetted package repositories in an automated manner, and languages that encourage using thousands of random garbage microdependencies rather than well-vetted, versioned libraries.
@leoluk @GossiTheDog We should not be placing the burden of "users don't get hit with malware" on maintainers locking down their workflows in ways that might be exclusionary or inaccessible.
Instead, the platforms that want to deliver unvetted code as part of a "supply chain" 🤮 need to get their act together and find a way that newly-published unvetted code doesn't end up as part of anyone's build, but instead goes through multiple layers of delay where it's only available to people who intend to be testing an unvetted bleeding edge and understand the dangers. With channels to request rapid review of tiny security-critical changes when needed for expediting them.
@leoluk @GossiTheDog For the most part, none of these packages have any need for new versions to appear in anyone's builds for *months* if not years after publication, unless someone *specifically* has read the changes to the new version and sees a new feature they want from it.
LPM platforms should be designed around this basic principle that updates are mostly unwanted.
The only way anyone should ever get unexpected updates is if there's a serious security problem, in which case there should be a description of the problem and a small comprehensible patch prominently displayed.
IOW LPMs and similar platforms should behave like Debian Stable.
@dalias @leoluk That approach doesn't work. Suppose you're on version X, and as time goes by versions X+1, X+2... are released. You don't upgrade.
Then they release version X+N which contains a security fix you do need. By delaying your upgrades you now have a pile of unrelated changes to include, at exactly the wrong time.
Kevin Beaumont
Leo@ALLES
Cassandrich
mr. waddlesplash
Nik