CVE-2021-44228 (log4j) Apache vulnerability - How ... - ServiceNow Community

CVE-2021-44228 (log4j) Apache vulnerability - How does this affect security in ServiceNow?

Kelly Logan
Kilo Sage

‎12-10-2021 07:19 AM

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Exploit code has been released for a serious code-execution vulnerability in Log4j, an open-source logging utility that's used in countless apps, including those used by large enterprise organizations, several websites reported on last Thursday.

https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/

Labels:
  • 19,565 Views
27 REPLIES 27

Larra Lapid2
Tera Expert

‎12-10-2021 01:12 PM

Hi Kelly, have you received any additional info about this? Wondering myself. 

0 Helpfuls

robebe07
Tera Contributor
In response to Larra Lapid2

‎12-10-2021 01:16 PM

I created a case on this earlier. See below.

 

2021-12-10 11:01:12 PST - Jerry Destine (NOW)

Additional comments

 


Hi Robert,

Our team is in the process of the investigation.
At this point in time, I do not have any additional information I can provide.

As soon as I receive ANY additional information I will share it with you ASAP.

Please allow us the opportunity to complete our investigation.
I will be sure to follow up with you but please let me know if you have any questions in the meantime.

Best,
Jerry

 

2021-12-10 10:50:18 PST - Robert Beck

Additional comments

 


According to this article linked below, any version that is 2.14 is vulnerable unless the following temporary fix has been put in place. Are you saying that our midservers running 2.14 have this temporary fix in? If so, how can I validate that?

 

Temporary Mitigation​
As per this discussion on HackerNews:

 

The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3].

 

If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are:

 

Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109 or,

 

Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior.

 

https://www.lunasec.io/docs/blog/log4j-zero-day/

Issue: ​
Earlier today, ServiceNow became aware of a 0-day exploit in the popular Java logging library, "log4j."
Our initial investigation has not uncovered any vulnerability in our systems.
We will continue to investigate and perform further testing to ensure no impact.

 

Josh R
Tera Contributor

‎12-10-2021 02:15 PM

I can't speak to the version of midserver's log4j (or if it is using the following config file), but I do see a log4j.xml file that appears to be a config file that references %m in a few areas... please keep us posted in this thread if additional information becomes available.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

 

<log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'>

 

<appender name="SYSTEM" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="${com.collation.home}/log/error.log"/>
<param name="Append" value="true"/>
<param name="MaxFileSize" value="${com.collation.log.filesize}"/>
<param name="MaxBackupIndex" value="${com.collation.log.filecount}"/>
<param name="Threshold" value="ERROR"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%d{ISO8601} %X{service} [%t] %x %p %c{2} - %m\n"/>
</layout>
</appender>

 

<appender name="L2" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="${com.collation.home}/log/l2.log"/>
<param name="Append" value="true"/>
<param name="MaxFileSize" value="${com.collation.log.filesize}"/>
<param name="MaxBackupIndex" value="${com.collation.log.filecount}"/>
<param name="Threshold" value="DEBUG"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%d{ISO8601} %X{service} [%t] %x %p %c{2} - %m\n"/>
</layout>
</appender>

 

<category name="com.collation">
<priority value="debug"/>
<appender-ref ref="SYSTEM"/>
</category>

<category name="com.collation.topomgr.topobuilder.agents.l2">
<priority value="debug"/>
<appender-ref ref="L2"/>
</category>

<category name="com.collation.discover.agent.net.BridgeSnmpAgent">
<priority value="debug"/>
<appender-ref ref="L2"/>
</category>

</log4j:configuration>

Malgorzata Maku
Tera Contributor

‎12-10-2021 06:08 PM

Any status on this?

 

0 Helpfuls