Important Update Regarding Apache Log4j

In December 2021, a critical vulnerability in Apache Log4j, a logging library that’s used in millions of Java-based applications, came to light.

SysAid shifted resources accordingly to address this critical issue and have been updating our product as fast as the updates are coming out from Apache. 

We have addressed this vulnerability on two fronts – with an immediate workaround as well as the release of both Cloud and On-premises versions that include a fix. We strongly encourage you to implement the workaround as soon as possible where applicable as detailed below.

We continue to monitor the situation and adapt as necessary, your security is our top priority. Based upon our initial analysis, we do not expect customers to experience any impact as a result of the workaround. If you have any issues, please contact us ASAP.

• Immediate workaround is not necessary anymore as version upgrades have been implemented.  

• Permanent fix

• • Version 21.4.60 provided preliminary fix 
  • Version 21.4.70 included Apache Log4j 2.17.0 upgrade 
  • Version 22.1.10 will address the latest Apache Log4j upgrade 2.17.1

General rollout of this version will take place between January 9th, 2022 and January 16th, 2022.

• Permanent fix

• • On-premises version 21.4.45 that is in general availability includes the Apache Log4j  fix supporting Apache Log4j version 2.17.1. To download the new version, click here.
  • NOTE: After upgrade, in order to perform a proper security audit, please be aware that when upgrading the version, old jar files are not deleted by default and are copied from:
    …\SysAidServer\root\WEB-INF\lib\
    to:
    …\SysAidServer\root\WEB-INF\lib_old\
    This is done as part of a backup protocol in case issues arise while an upgrade is in process.
    However, when performing a security audit these copied archive files will still raise a flag. It is recommended when performing the security audit to delete the folder “lib_old”.

• Immediate workaround –

• • The immediate workaround is not necessary once the SysAid version is upgraded to v21.4.45.
  • To mitigate the risk of this vulnerability until you upgrade to the new version,  we ask you to update the configuration of both your SysAid and RDS servers. 
    1. Set your system properties as follows (the only change you must make is in bold as seen below):
       SysAid Server:

…\SysAidServer\conf\wrapper.conf

RDS:

…\SysAidRemoteDiscovery\conf\wrapper.conf

# Java Additional Parameters

wrapper.java.additional.1=-Dcatalina.home=./tomcat

wrapper.java.additional.2=-Djava.io.tmpdir=./tomcat/temp

wrapper.java.additional.3=-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true

wrapper.java.additional.4=”-Xss256k”

wrapper.java.additional.5=-XX:MaxPermSize=256m

wrapper.java.additional.6=-XX:PermSize=128m

wrapper.java.additional.7=-Dlog4j2.formatMsgNoLookups=true

wrapper.java.command=C:\Program Files\SysAidRemoteDiscovery\jre\bin\java.exe

NOTE: Add the parameter and be sure to pay attention to the number in the parameter name (the last part i.e.- wrapper.java.additional.<Number>). It should be the next available sequence number – in the example above it was 8 for On-Premises.

2. Restart the SysAid Server.