Should we be worried: Apache log4j RCE 0-day exploit ??

[kritika-singh3]

Link: https://www.cyberkendra.com/2021/12/worst-log4j-rce-zeroday-dropped-on.html

[chadlwilson]

I believe we are fine, since GoCD uses logback as logging backend everywhere from what I can see. All log4j dependencies are bridged to slf4j and then go via logback as implementation.

~/Projects/community/gocd/gocd / master
$ ./gradlew allDependencies | grep log4j
+--- org.slf4j:log4j-over-slf4j:1.7.32

[arvindsv]

Agree. Looks fine. I'm surprised and relieved. :)

[darynsteelsword]

Just curious:

"since GoCD uses logback as logging backend everywhere"

Is that from a particular version or has this always been the case pls?

[arvindsv]

Sorry, I didn't realise GitHub discussions has threads (🤦). My response to you is below (the one mentioning the relevant commit).

[darynsteelsword]

Nae worries, thanks very much for the swift update.

[arvindsv]

The relevant commit might be: f501efc [so, somewhere in the 16.x release].

The last commit which references org.apache.log4j seems to be: 84150be

The TFS SDK might be the one component which uses log4j. So, if you're using TFS, then this is something to keep an eye on. The JAR used is: tfs-impl-14.jar which has com.microsoft.tfs.sdk-14.118.0.jar in it, I believe. A relevant message in that first commit says: "all logging performed by tfs sdk via its packaged log4j and commons-logging classes are delelaged to the parent classloader instead, so that they log using the *-over-slf4j APIs".

[chadlwilson]

Even when GoCD used log4j 5 years ago prior to f501efc, that was log4j 1.2 which is not vulnerable to this issue. As far as I can see, GoCD has never used log4j2, at least in its open source days.

Similarly, the log4j version bundled with the TFS SDK is log4j 1.2, so there should also be nothing to worry about there. Everything inside that TFS jar is org.apache.log4j, not org.apache.logging.log4j Reference:

The main package in version 1 is org.apache.log4j, in version 2 it is org.apache.logging.log4j

[ketan]

Original author of the commit f501efc here ;)

As a design decision - we moved over to logback as a common logging framework, using slf4j facade. Since 3rd party dependencies used a variety of logging frameworks (including log4j, log4j2, commons-logging), the slf4j facade has drop-in class-compatible versions of most of these logging frameworks — they simply delegate the logging to slf4j, which in turn forwards it over to logback. The intent was that users could then configure logging for all frameworks and subsystems using a single log file, instead of several log files for each logging framework.

For the tfs-sdk — I recall I had explicitly spent time in verifying that tfs uses the log4j classes from slf — it might be useful to re-test (even better add an explicit test for it).

[arvindsv]

Related: https://groups.google.com/g/go-cd/c/zobQ24Oz8rM/m/3hjTUbuCCwAJ (A claim that GoCD 20.6.0 (and maybe 21.3.0) is vulnerable)

Also, announcement sent to the GoCD mailing list pointing to this discussion: https://groups.google.com/g/go-cd/c/d-uA9v760Bg/m/VAWsMPCCCwAJ

[chadlwilson]

The propensity for false positives here seems high until tools start incorporating good heuristics/hashes of affected jars, and the naming of jars is confusing for those not familiar with logging facades and the SLF4J bridging adapters in Java.

I think GoCD is not affected throughout at least the last 7 years, but no harm in digging deeper and trying a few different approaches.

[vpoyraz]

I wasn't aware of this discussion prior to raising the issue here: #9934. Happy to have this closed off if we are certain the vulnerability does not directly affect GoCD.

[arvindsv]

I think it's fine to leave it open for a while, so that others don't open similar issues immediately (and instead get redirected to this discussion).

[TimJDFletcher]

I've used one of the scanning tools for log4j to look over the gocd jar files and the scanner found these 2 files:

My java knowledge is not good enough to know if these are relevant here

╰─ ./log4shell scan ./gocd
5:46PM INF identified vulnerable path fileName=org/apache/log4j/net/SocketNode.class path=gocd/go-server-21.3.0/lib/go.jar::defaultFiles/tfs-impl-14.jar::lib/com.microsoft.tfs.sdk-14.118.0.jar versionInfo="log4j 1.2.13-1.2.14"
5:47PM INF identified vulnerable path fileName=org/apache/log4j/net/SocketNode.class path=gocd/go-server-21.3.0/lib/go.jar::lib/tfs-impl-14.jar::lib/com.microsoft.tfs.sdk-14.118.0.jar versionInfo="log4j 1.2.13-1.2.14"

[arvindsv]

@TimJDFletcher This is what Ketan mentioned above and that usage should be delegated to slf4j as well. The commit mentions this being done as well: f501efc

If it is done correctly, then the fact that the file is there is not an issue. We can't change it, since it's within a JAR from Microsoft -- but it shouldn't be used.

As Ketan said, it might be best to check. The question then becomes: How? [Maybe creating a TFS material with ${jndi:...}.

tl; dr - current understanding is that it isn't an issue, but need to confirm.

[TimJDFletcher]

Ah missed that part about tfs before going digging.

[TimJDFletcher]

I wonder if some tfs commit strings ever get logged...

[arvindsv]

It might, but the idea of that change (especially these lines) is that the logging should delegated back to slf4j and then logback. So, logging of those commit strings shouldn't matter.

If anyone reading this / comes across this wants to test it, please do. If it is vulnerable, we would probably have to remove the TFS functionality.

[chadlwilson]

I've dug a bit deeper, and that lunasec tool is flagging specific SocketNode classes from 1.x log4j nested within com.microsoft.tfs.sdk-14.118.0.jar due to concern about CVE-2019-17571 which is a different thing to the canonical log4shell CVE-2021-44228 issue here.

Furthermore, even if in GoCD's case the log4j-over-slf4j "override" wasn't working for the TFS client jar logging, that particular 2019-era CVE requires use of the SocketServer from log4j, which would require specific configuration to enable alongside the SocketAppender - which I can't find any evidence of GoCD ever having in its configuration.

Furthermore, the current embedded com.microsoft.tfs.sdk-14.118.0.jar has a bundled configuration of the below, which even if it was being used does not include SocketNode, SocketServer etc, so I believe further not vulnerable to CVE-2019-17571.

# The TFS SDK for Java default log4j configuration.  See the
# com.microsoft.tfs.logging.config.Config class's documentation for how
# to override this configuration.

# Set root logger level to INFO and its only appender to A1.
log4j.rootLogger=WARN, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-5p [%t] %c{1} - %m%n

[arvindsv]

@TimJDFletcher brought this to my notice just now:

https://jira.qos.ch/browse/LOGBACK-1591
http://logback.qos.ch/news.html

It's not clear if logback is impacted in any way, though. Meaning: There is JNDI lookup code, but it's not clear if it can get triggered unless the config is changed knowingly. But they do mention RCE ...

As a precautionary meausure, logback is being upgraded (#9935). Can make a release once the pipelines finish, if it is clear it is necessary.

[arvindsv]

Further analysis: It looks like this is what led to the logback release: https://github.com/cn-panda/logbackRceDemo

As mentioned in the "Project address" section, there needs to be an arbitrary file upload vulnerability which already exists, to take advantage of, to update the logback config file. If you have access to an arbitrary file upload vulnerability, there is much more damage that can be done (you can change the GoCD config file itself, for instance). (Also see: cn-panda/logbackRceDemo#1)

So, this is unlikely to be a major problem / an urgently needed fix. But, the upgrade is in progress, and will be ready if needed.

Edited later: Also see this comment in the original logback Jira thread.