Log4J Vulnerability

[Kaj Wierda]

The Automic product engineering teams are actively investigating how the Log4J vulnerability may impact Automic Automation software and related integrations.

This is our top priority and the Broadcom Automic Automation Engineering team will be releasing hotfixes containing the latest log4j package as soon as possible.

In the meantime, you can mitigate the issue today by following the instructions in the Knowledge Base article.

------------------------------
Kaj Wierda
Sr. Product Line Manager | Automation

Broadcom Software
------------------------------

[Carsten Schmitz]

(this post was updated several times to provide further detail)

Hi.

Our security division is on high alert due to the severity of this, and the attacks that are already showing up in our perimeter.

They tell me that currently, it is widely disputed whether version 1.x of log4j is unaffected. Worse, if it should be affected, the mitigation parameter that is suggested isn't available for 1.x, it's only available for 2.x.

They also dispute that using a newer Java JRE provides automatic protection.

Additionally, I find two more CVE that are filed against 1.x, both rated at a severity of 7.5 CVE score, and at least one allowing arbitrary code execution.

I looked briefly at our components and found references to log4j in the following components:

AWI:
------
# grep -ir log4j
META-INF/maven/ch.qos.logback/logback-classic/pom.xml: <artifactId>log4j-over-slf4j</artifactId>
META-INF/maven/ch.qos.logback/logback-classic/pom.xml: <!-- Must be after log4j-over-slf4j:
META-INF/maven/ch.qos.logback/logback-classic/pom.xml: * we want to use the classes from log4j-over-slf4j (so it must come first);
META-INF/maven/ch.qos.logback/logback-classic/pom.xml: * we want to use log4j.dtd from log4j. -->
META-INF/maven/ch.qos.logback/logback-classic/pom.xml: <groupId>log4j</groupId>
META-INF/maven/ch.qos.logback/logback-classic/pom.xml: <artifactId>log4j</artifactId>

$ hexdump -C ch/qos/logback/classic/spi/CallerData.class | grep log4j
00000570 6c 6f 67 34 6a 2e 43 61 74 65 67 6f 72 79 01 00 |log4j.Category..|

$ hexdump -C ch/qos/logback/classic/log4j/XMLLayout.class | grep log4j
00000210 6c 6f 67 34 6a 2f 58 4d 4c 4c 61 79 6f 75 74 3b |log4j/XMLLayout;|
000006d0 0c 00 e5 00 e2 01 00 15 3c 6c 6f 67 34 6a 3a 65 |........<log4j:e|
00000770 00 8a 01 00 12 3c 2f 6c 6f 67 34 6a 3a 6d 65 73 |.....</log4j:mes|
00000790 00 f6 00 f7 01 00 1c 20 20 3c 6c 6f 67 34 6a 3a |....... <log4j:|
000007e0 00 fb 00 fc 01 00 1d 20 20 3c 6c 6f 67 34 6a 3a |....... <log4j:|
000008c0 20 3c 6c 6f 67 34 6a 3a 64 61 74 61 01 00 07 20 | <log4j:data... |
00000910 0d 0a 20 20 3c 2f 6c 6f 67 34 6a 3a 70 72 6f 70 |.. </log4j:prop|
00000990 69 63 2f 6c 6f 67 34 6a 2f 58 4d 4c 4c 61 79 6f |ic/log4j/XMLLayo|




RA FTP Agent:
------------------
log4j references found in files:

$ hexdump -C groovy/util/logging/Log4j2$Log4j2LoggingStrategy.class | grep -i log4j
00000020 2f 4c 6f 67 34 6a 32 07 00 01 01 00 10 6a 61 76 |/Log4j2......jav|
00000060 6f 6e 07 00 05 01 00 0b 4c 6f 67 34 6a 32 2e 6a |on......Log4j2.j|
000001c0 69 6c 2f 6c 6f 67 67 69 6e 67 2f 4c 6f 67 34 6a |il/logging/Log4j|
000001d0 32 24 4c 6f 67 34 6a 32 4c 6f 67 67 69 6e 67 53 |2$Log4j2LoggingS|
00000310 6c 6f 67 67 69 6e 67 2f 4c 6f 67 34 6a 32 24 4c |logging/Log4j2$L|

$ hexdump -C groovy/util/logging/Log4j$Log4jLoggingStrategy.class | grep -i log4j
00000020 2f 4c 6f 67 34 6a 07 00 01 01 00 10 6a 61 76 61 |/Log4j......java|
00000060 6e 07 00 05 01 00 0a 4c 6f 67 34 6a 2e 6a 61 76 |n......Log4j.jav|
000001c0 2f 6c 6f 67 67 69 6e 67 2f 4c 6f 67 34 6a 24 4c |/logging/Log4j$L|
000001e0 65 67 79 07 00 12 01 00 14 4c 6f 67 34 6a 4c 6f |egy......Log4jLo|
00000310 6e 67 2f 4c 6f 67 34 6a 24 4c 6f 67 34 6a 4c 6f |ng/Log4j$Log4jLo|

$ hexdump -C groovy/util/logging/Log4j.class | grep -i log4j
00000020 2f 4c 6f 67 34 6a 07 00 01 01 00 10 6a 61 76 61 |/Log4j......java|
00000060 6e 07 00 05 01 00 0a 4c 6f 67 34 6a 2e 6a 61 76 |n......Log4j.jav|
000001c0 2f 6c 6f 67 67 69 6e 67 2f 4c 6f 67 34 6a 24 4c |/logging/Log4j$L|
000001e0 65 67 79 07 00 12 01 00 14 4c 6f 67 34 6a 4c 6f |egy......Log4jLo|
00000310 6e 67 2f 4c 6f 67 34 6a 24 4c 6f 67 34 6a 4c 6f |ng/Log4j$Log4jLo|

$ hexdump -C groovy/util/logging/Log4j2.class | grep -i log4j
00000020 2f 4c 6f 67 34 6a 32 07 00 01 01 00 10 6a 61 76 |/Log4j2......jav|
00000060 6f 6e 07 00 05 01 00 0b 4c 6f 67 34 6a 32 2e 6a |on......Log4j2.j|
000001c0 69 6c 2f 6c 6f 67 67 69 6e 67 2f 4c 6f 67 34 6a |il/logging/Log4j|
000001d0 32 24 4c 6f 67 34 6a 32 4c 6f 67 67 69 6e 67 53 |2$Log4j2LoggingS|
00000310 6c 6f 67 67 69 6e 67 2f 4c 6f 67 34 6a 32 24 4c |logging/Log4j2$L|


Server/Engine Plugins
---------------------------
log4j references/strings found in lib/commons-logging.jar, lib/logback-classic.jar, both contained in server/bin/plugins/com.automic.sso.jar.

commons-logging.jar contains lib/org/apache/commons/logging/impl/Log4JLogger.class:

hexdump -C Log4JLogger.class | grep log4j
00000130 63 68 65 2f 6c 6f 67 34 6a 2f 4c 6f 67 67 65 72 |che/log4j/Logger|
00000160 63 68 65 2f 6c 6f 67 34 6a 2f 50 72 69 6f 72 69 |che/log4j/Priori|
000001d0 6f 72 67 24 61 70 61 63 68 65 24 6c 6f 67 34 6a |org$apache$log4j|
000001f0 72 67 24 61 70 61 63 68 65 24 6c 6f 67 34 6a 24 |rg$apache$log4j$|
000002a0 63 68 65 2f 6c 6f 67 34 6a 2f 4c 6f 67 67 65 72 |che/log4j/Logger|
00000570 69 62 6c 65 20 6c 6f 67 34 6a 20 6d 69 73 63 6f |ible log4j misco|
000006a0 6f 72 67 2f 61 70 61 63 68 65 2f 6c 6f 67 34 6a |org/apache/log4j|
00000790 70 61 63 68 65 2f 6c 6f 67 34 6a 2f 4c 6f 67 67 |pache/log4j/Logg|
000007d0 63 68 65 2f 6c 6f 67 34 6a 2f 50 72 69 6f 72 69 |che/log4j/Priori|
00000810 72 67 2f 61 70 61 63 68 65 2f 6c 6f 67 34 6a 2f |rg/apache/log4j/|
00000880 67 2f 61 70 61 63 68 65 2f 6c 6f 67 34 6a 2f 4c |g/apache/log4j/L|
000008b0 61 63 68 65 2f 6c 6f 67 34 6a 2f 50 72 69 6f 72 |ache/log4j/Prior|


Additionally, the META-INF/MANIFEST.MF file says that SOME log4j classes are used:

# grep -C 1 log4j META-INF/MANIFEST.MF
n,ch.qos.logback.core.util,ch.qos.logback.classic.pattern";version="1
.0.13",ch.qos.logback.classic.log4j;uses:="ch.qos.logback.core.helper
s,ch.qos.logback.classic,ch.qos.logback.core,ch.qos.logback.classic.s
--
0",ch.qos.logback.classic.joran.action;version="1.0",ch.qos.logback.c
lassic.jul;version="1.0",ch.qos.logback.classic.log4j;version="1.0",c
h.qos.logback.classic.net;version="1.0",ch.qos.logback.classic.net.se

 
Can you please urgently let us know whether these are safe despite those references, and which major versions of log4j are in use here, if any?

p.s. this is not necessarily complete; I didn't scour ALL the jar files for these components, just some.

Thanks.

[Carsten Schmitz]

@Kaj Wierda Can we get some insights please? Our security people are strongly requesting us to get these responses.

[Kaj Wierda]

All Automic components impacted by CVE-2021-44228 are listed in the KB article I shared in my original message: https://knowledge.broadcom.com/external/article?articleId=230308

We continuously update this KB article (last update was yesterday). If the component is not listed in the KB article, it is not impacted by CVE-2021-44228.

We will look at other potential vulnerabilities related to use of log4j once the fixes for CVE-2021-44228 are released.

------------------------------
Kaj Wierda
Sr. Product Line Manager | Automation

Broadcom Software
------------------------------

[Carsten Schmitz]

Hi @Kaj Wierda.

We had wished for some further details addressing our concerns, but alas.

But what I'm actually here for is to give a little friendly heads-up: Maybe you are already considering this, but there is a new CVE, because the first one did not fix the issue fully. So when your developers upgrade log4j components, they may want to keep this in mind also:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Nevermind. I saw after the post that you updated your article to already reflect that.

Best regards,

[Alexander Trenker]

The Knowledge Base article was updated with all the download links.
Please let us know if you have any further questions.

[Pete Wirfs]

Is RA FTP impacted.

I would assume not since it is not mentioned.  But assumptions make me uncomfortable.

When we search our RAFTP v4.0.9 bin folders for "log4j", we discover hits in bsf-2.4.0.jar, commons-logging-1.2.jar, and groovy-all.jar.

------------------------------
Pete Wirfs
SAIF Corporation
Salem Oregon USA
------------------------------

[Alexander Trenker]

Hi Pete,
The bsf-2.4.0.jar is part of the RA Core and is not affected.

Cheers,
Alexander

[Carsten Schmitz]

Sorry, but:

I already asked about RA FTP with detailed findings, and Broadcom shuts me down by sending me the original article.

Then @Pete Wirfs asks what seems like the same question again:

> When we search our RAFTP v4.0.9 bin folders for "log4j", we discover hits in bsf-2.4.0.jar, commons-logging-1.2.jar, and groovy-all.jar.​

And your answer appears to be:

> The bsf-2.4.0.jar is part of the RA Core and is not affected

Thus, unless I am missing something, totally neglecting to give any information on the other two components Pete asked (and I asked about earlier).

I feel like this is not the most reassuring way Broadcom could possibly deal with customer concerns!

Best regards.

[Michael Lowry]

@Kaj Wierda, would you please comment specifically on the log4j references inside the RA FTP solution?​

[Kaj Wierda]

Coming back to the occurrences of the string "log4j" when searching the 3 libraries bsf-2.4.0.jar, commons-logging-1.2.jar, and groovy-all.jar.
Internally we do not use this crude scanning method as it would yield a lot of false positives. We use proven software composition analysis tools to ensure we (and our customers) have a reliable picture of the references that are actually in use. This is the information we base our KB articles on. 

None of these 3 libraries are affected by the log4j vulnerabilities. bsf-2.4.0.jar does not use log4j at all.

commons-logging-1.2.jar (https://mvnrepository.com/artifact/commons-logging/commons-logging/1.2) has an optional dependency on log4j but we do not use that, neither do we deliver log4j as part of the jar file.

------------------------------
Kaj Wierda
Sr. Product Line Manager | Automation

Broadcom Software
------------------------------

[Carsten Schmitz]

@Alexander Trenker @Kaj Wierda Afraid you may need another update.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105

(I guess now everyone and their hacking-subculture-associated mothers are looking at log4j, so 2022 will probably be the year where we'll be getting many, many more of these ...)​​

[Kaj Wierda]

We will be releasing updates as part of our regular update process to address CVE-2021-45105.

In the meantime, the mitigation steps as outlined in our KB article https://knowledge.broadcom.com/external/article?articleId=230308 also apply to CVE-2021-45105.

------------------------------
Kaj Wierda
Sr. Product Line Manager | Automation

Broadcom Software
------------------------------