CVE-2021-44228 (Log4j) - Don't Panic

[Kieran Anson]

The latest and greatest vulnerability to hit corporations is the Log4j vulnerability that allows remote code execution on platforms using the java library. 

How does this impact ServiceNow?

ServiceNow uses Log4j like many other java based applications for its great logging ability. It's used on the core platform as the backend; for MID servers; and for edge encryption proxies.

Do I need to be concerned?

ServiceNow's posture on the 0-day exploit is that instances of the Now Platform are running a version of Java that, by default, implements settings to prevent this vulnerability. More clearly, the below settings are used by default by the JDK versions in use that mitigate against this potential vulnerability

• com.sun.jndi.ldap.object.trustURLCodebase=false
• com.sun.jndi.rmi.object.trustURLCodebase=false 

What about my deployed MID servers?

ServiceNow MID Servers, which you deploy behind your firewalls, are lightweight Java Virtual Machines (JVM). MID server code does not use log4j directly and disabled third-party library usage of log4j. Moreover, the OpenJDK versions that ship with the MID installation file(s) are not vulnerable.

• Paris: OpenJDK 1.8.0_231

• Quebec: OpenJDK 11.0.8

• Rome: OpenJDK 11.0.9.1

These versions have the same trust settings as above and no further changes need to be made.

How can I tell what Java version I have?

You can do this quite simply via your operating systems command-line tool using "java -version". The screenshot below is a Windows environment

t

I'm using an older JDK / a JDK not shipped by ServiceNow

If you're on an older release of ServiceNow or using a different vendors Java edition, you can add a property to the MID wrapper configuration file:

• Navigate to your MID server directory
• Navigate to /agent/conf/wrapper.override.conf
• Add the following to parameters section towards the bottom of the file:
• • wrapper.java.additional.209=-Dlog4j2.formatMsgNoLookups=true
  • wrapper.java.additional.210=-Dcom.sun.jndi.ldap.object.trustURLCodebase=false
  • wrapper.java.additional.211=-Dcom.sun.jndi.rmi.object.trustURLCodebase=false
  • wrapper.java.additional.212=-Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false

Where do I go for more information?

ServiceNow customers with Support access can keep up to date via KB1000959

*I'm not affiliated with ServiceNow in any way, I'm just a customer wishing to share wisdom with others. Customers should reference the above Support Article on ServiceNow's official posture and remediation advice*

[James27]

The JDK settings are set to mitigate these vulnerabilities by default, but can these settings be changed? If they can be changed, how do I check the settings to be sure they have not been changed in my instance?

[Jeff Boltz1]

can we do belt and suspenders - put the wrapper.java.additional.209=-Dlog4j2.formatMsgNoLookups=true even though the 2 properties are set?

[Kieran Anson]

Evening Jeff,

Yes you can if you want that extra layer of comfort - it won't impact performance of the MID starting and running.

Just make sure you restart the MID service after changing the settings.

[Kieran Anson]

The beauty of SaaS is that the java layer is uniform across all SN instances and SN are the only ones who are able to directly indirect with it (we interact with the JavaScript & Rhino abstraction layers).

If you're on-prem, it's a different story and you (the customer) is responsible for the security and operation of the instance.

[Jeff Boltz1]

If we are not using ServiceNow JDK, how do we view or update 

• com.sun.jndi.ldap.object.trustURLCodebase=false
• com.sun.jndi.rmi.object.trustURLCodebase=false

Does wrapper.java.additional.209=-Dlog4j2.formatMsgNoLookups=true do that for us?

[Jeff Boltz1]

Thanks!

If we are not using ServiceNow JDK, how do we view or update 

• com.sun.jndi.ldap.object.trustURLCodebase=false
• com.sun.jndi.rmi.object.trustURLCodebase=false

Does wrapper.java.additional.209=-Dlog4j2.formatMsgNoLookups=true do that for us?

[Kieran Anson]

Hi Jeff,

Setting the following in the wrapper-override.conf file implicitly sets the properties to mitigate the issue:

• wrapper.java.additional.209=-Dlog4j2.formatMsgNoLookups=true 
• wrapper.java.additional.210=-Dcom.sun.jndi.ldap.object.trustURLCodebase=false
• wrapper.java.additional.211=-Dcom.sun.jndi.rmi.object.trustURLCodebase=false
• wrapper.java.additional.212=-Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false

[Jeff Boltz1]

Thanks again!  Very helpful

[rogier666]

I've read that the config that is mentioned protects against the classloader exploit. There is also an exploit that uses Serialized Payloads. Can you confirm that ServiceNow and midserver are also protected for this attack scenario? https://twitter.com/marcioalm/status/1470361495405875200

[Kieran Anson]

This would be a question best posed to Support (formerly HI) via a case.

[Ashu6]

How can I determine log4j version ? The log4j.xml is not giving me any indication of the version it is using. the locate log4j | grep -v log4js is also not helping me. Please guide. Thank you.

[Kieran Anson]

There are a collection of options, but ideally your enterprise should be using a threat and vulnerability application to find instances of log4j.

• dpkg -l | grep liblog4j

• dpkg -l | grep log4

• find / -name log4j-core-*.jar

• locate log4j | grep -v log4js

[Thierry Klein]

Hi

Maybe a dummy question (I'm not a Java expert), but if this component is not used on MID server and no other library use it, can we remove the JAR file without any impact on the MID Server ?

It will allow to remove warning from Vulnerability scan tools.

Please guide.

[Kieran Anson]

Hi Thierry,

It's present as a dependency so wouldn't be wise to delete it, but it is equally unused. Depending on how SN run the JVM, their might be checks in place to validate that no classes have been inserted or removed (which could indicate a compromise).

You can manually upgrade the log4j class file

1. Download the updated 2.17.0 zip file containing (binaries) the jar files, available here: https://logging.apache.org/log4j/2.x/download.html

2. Extract the downloaded files to a temporary directory
3. Rename log4j-api-2.17.0.jar to log4j-api.jar
4. Rename log4j-core-2.17.0.jar to log4j-core.jar
5. Rename log4j-slf4j-impl-2.17.0.jar to log4j-slf4j-impl.jar
6. Stop your MID server
7. Navigate to <MID_SERVER_INSTALL>/agent/lib
8. Check to see if you have log4j-api.jar, log4j-core.jar and log4j-slf4j-impl.jar -- If you only have one log4j.jar file in /agent/lib - then you are still on the older non-vulnerable version of log4j.
9. Optional: Backup old files by cutting or copying them to another directory
10. Copy your renamed files from your temp directory to <MID_SERVER_INSTALL>/agent/lib making sure to overwrite existing files.
11. Start your MID Server

[Ashish]

Hi Anson,

 Despite manually upgrading the log4j files as described above, the agent\lib folder still has log4j.jar file which gets flagged during the vulnerability scans.

Removing log4j.jar files makes the Mid Server go down as somehow it is required to keep the associated services running.

Any suggestions.

Thanks,

Ashish Ranjan