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)

In T298854#7608374, @MoritzMuehlenhoff wrote:

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.

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)

In T298854#7607990, @Joe wrote:

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.

In T298854#7612222, @santhosh wrote:

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.

In T298854#7612222, @santhosh wrote:

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