Page MenuHomePhabricator

NPM "colors" and "faker" package vulnerability audit
Closed, InvalidPublic

Description

The NPM package colors has recently been intentionally vandalized by its creator, causing anyone its use on at least package versions colors@1.4.1 and colors@1.4.44-liberty-2 to trigger an infinite loop. It seems there's also two new versions

Looking through the usage on codesearch with this query, I do not see any instances where these versions would be pulled, but it's likely a good idea to move off any usage of this package wherever possible.

The faker package was also disrupted, but in a less extreme way on version 6.6.6. See this codesearch query for it.

See also: Synk's article (HN) or Bleeping Computer's article (HN).

Event Timeline

Sadly that code search is not a complete guarantee. For things we build with the pipeline, we might not have a package.json for all dependencies, so we will have to do a manual check of the docker images.

The nodejs12-devel image contains node-colors as shipped in Debian Bullseye, but that version isn't affected (it predates the vandalised release)

The nodejs12-devel image contains node-colors as shipped in Debian Bullseye, but that version isn't affected (it predates the vandalised release)

Yes, the problem might arise with images that include that dependency indirectly, like changeprop.

Reedy moved this task from Incoming to Watching on the Security-Team board.
Reedy added a project: SecTeam-Processed.

Wikimedia services depending on service-runner is affected by this issue. service-runner depends on limiation library and it depends on wikimedia-kad-fork library. wikimedia-kad-fork defines dependency to "colors": "^1.0.3". An npm install with that dependency declaration pulled colors 1.4.1 version and it is problematic. npm had removed the problematic versions, but found a case where newer version from npm cache was used.

Noticed this today while checking gerrit CI failures for cxserver service - https://integration.wikimedia.org/ci/job/service-pipeline-test/10864/console. This CI is based on docker-registry.wikimedia.org/nodejs12-devel image.

https://github.com/wikimedia/kad does not use a package lock file. it is also quite outdated fork(T200374)

Sadly that code search is not a complete guarantee. For things we build with the pipeline, we might not have a package.json for all dependencies, so we will have to do a manual check of the docker images.

Good to know; thank you.

wikimedia-kad-fork defines dependency to "colors": "^1.0.3". An npm install with that dependency declaration pulled colors 1.4.1 version and it is problematic. npm had removed the problematic versions, but found a case where newer version from npm cache was used.

Ack: I swapped around ~1.0.3's meaning compared to ^1.0.3's. This means there is at least some problematic dependencies on colors according to the codesearch linked in the task description; sorry about that.

As discussed on IRC, another concrete example of this affecting Wikimedia infrastructure - garbled jenkins console output: https://integration.wikimedia.org/ci/job/service-pipeline-test/10879/console, from https://gerrit.wikimedia.org/r/752693.

Wikimedia services depending on service-runner is affected by this issue. service-runner depends on limiation library and it depends on wikimedia-kad-fork library. wikimedia-kad-fork defines dependency to "colors": "^1.0.3". An npm install with that dependency declaration pulled colors 1.4.1 version and it is problematic. npm had removed the problematic versions, but found a case where newer version from npm cache was used.

So to fix this immediate issue with service-runner (probably our largest attack surface for this issue?), can we update the Wikimedia kad fork and pin to the last good version of colorsjs (1.4.0 is recommended by Sonatype), tag a new release and then update limitation and service-runner with new tags as well? It looks like most versions of service-runner used by Wikimedia-affected services specify caret versions in the 2.x.x range, so we'd probably want to tag both 2.9.1 and 3.1.1 releases of service-runner with this security fix. If folks are generally comfortable with this approach, I'm happy to get some pull requests/gerrits going. (I am not aware of a great way of security-patching services like what we do for MW-related issues, etc. and the severity of this vuln - basically obscuring vandalism in certain contexts - might not warrant a fully-embargoed approach like that anyways.)

can we update the Wikimedia kad fork and pin to the last good version of colorsjs (1.4.0 is recommended by Sonatype), tag a new release and then update limitation and service-runner with new tags as well?

Yes please.

In long term, T200374 and finding better maintained replacement for wikimedia-kad-fork may be needed.

Update: It appears github has pulled the malicious versions of colors? Tags appear to now stop at 1.4.0, which was the last "good" version of the package, from 2019. npm seems to indicate the same. I suppose colors will just be frozen at this version, possibly forever, unless a trustworthy maintainer steps forward? Anyhow, in looking at various package-lock.json files, I'm not seeing anything pinning colors at greater than 1.4.0 (not that that would even work now) and I'm not aware of any ongoing complaints of Wikimedia CI still being obfuscated, etc. So this issue is likely lower-priority or even invalid. Of course there's still the related issue of T200374, which is not great.

Proposing to close ticket as invalid nowadays

sbassett moved this task from Watching to Our Part Is Done on the Security-Team board.

Proposing to close ticket as invalid nowadays

I'm fine with that, for now.