Assess Linkerd 1.x vulnerability to CVE-2021-44228

[cpretzer]

Netty has released version 4.1.72 to address a vulnerability in log4j.

At the moment, I believe this is a low-risk vulnerability for Linkerd, based on following best practices which ensure that the viz UIs are available only to internal users who are authorized to access the network where Linkerd is running. Organizations with publicly exposed viz UI dashboards should take steps to secure those interfaces.

[olix0r]

@cpretzer

I believe this is a low-risk vulnerability for Linkerd, based on following best practices which ensure that the viz UIs are available only to internal users

Are you sure that this is only related to the UI? Wouldn't Linkerd's proxy interfaces be an attack vector?

[olix0r]

Also, are we sure that Netty is the only dependency that pulls in log4j? Does zookeeper use it, for instance?

[cpretzer]

Are you sure that this is only related to the UI? Wouldn't Linkerd's proxy interfaces be an attack vector?

Not 100% sure, but will dig into it

Also, are we sure that Netty is the only dependency that pulls in log4j? Does zookeeper use it, for instance?

Also need to research this and upgrade the appropriate libraries

[kadeatfox]

Hello @cpretzer - Which versions of linkerd would use this dependency?

It looks very much that the 1.7.4 version does in fact have this issue: https://github.com/linkerd/linkerd/tree/1.7.4/linkerd/main/src/main/resources

Is there any possibility this version will be updated?

[adleong]

The log4j dependency of netty is optional so Linkerd doesn't actually pull in log4j through netty at all.

The only place we pull in log4j is through zookeeper and the version zk depends on is 1.2.17 which is too old to be vulnerable to log4shell. log4j 1.2.17 is theoretically vulnerable to some different older RCE, but zk doesn't use that particular feature: see https://issues.apache.org/jira/browse/ZOOKEEPER-4423

I don't think any action is needed here

[cpretzer]

thank you for the quick analysis on this @adleong !

If no action is necessary, I'll close this and we can reopen, if necessary

[wmorgan]

Just a quick note about the log4j.properties file linked to by @kadeatfox above: Netty uses slf4j, which allows you to swap out logging implementations. That file is there for people who provide log4j as their logging implementation.

[wmorgan]

I'll also capture the investigation done by Jorge Vargas in #linkerd1 on the Linkerd community Slack, before Slack swallows the conversation forever:

Hello, sharing what I've found regarding log4j vuln in Linkerd. I cloned the linkerd/linkerd repo and checked out the 1.6.3 tag which is the version we're using, then I added a dependency tree plugin to sbt plugins file and after executing it I only see log4j 1.2.16 and 1.2.17, I'll do the same with tag 1.7.4
I also started looking into netty and if I'm not mistaken log4j was updated to v2 on version 4.1.65.final netty/netty#11264
on linkerd 1.6.3 I see netty 4.1.31.final
on linkerd 1.7.4 I see netty 4.1.47.final and log4j 1.2.16 and 1.2.17
from these dependencies it seems like linkerd 1 is safe, but log4j 1 has other vulnerabilities, although not as critical as log4shell

To summarize, as best we can tell, Linkerd 1.x is not vulnerable to CVE-2021-44228.