Skip to main content
As you are most likely aware, a critical vulnerability in Apache Log4j, a logging library that’s used in millions of Java-based applications, came to light over the weekend.



SysAid is addressing 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.

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.



Guidelines for Cloud and On-prem customers



For any questions or issues please contact us by

Email: helpdesk@sysaid.com

or reach out to our customer care live chat



Kind regards,

Maayan & the SysAid Team
Hi Ben,



Thanks for reaching out!



First, yes I can confirm that we indeed are going to include the log4j fix in the upcoming on-prem version, beta to be releaseed in the coming weeks. To get notified when beta is available please sign up here:

https://www.sysaid.com/pathfinders



Regarding the current workaround and the further updates from apache I have passed it on to our dev team to review and will update as soon aspossible.



Kind regards,

Maayan
Update for cloud customers - Log4j 2.17.0 is included in current rollout 21.4.70



While the workaround we shared with you recently has been effective, and the work on a permanent fix was on its way, we were also made aware of new security concerns in regard to Log4j 2.16.0 (CVE-2021-45105).



As a result, our new Cloud release 21.4.70 will include a Log4j update to version 2.17.0. This version will begin to be deployed on Sunday, Dec. 26.



There is no action expected of you at this time, but please confirm that your RDS is upgraded to the latest version following the deployment.



If you have questions or experience any issues, please contact us via our Helpdesk or live chat.



Happy holidays to you and yours,

Maayan & the SysAid team
Hi Maayan,



When will the on-premise customers receive the Log4j 2.17.0 update? Even the current on-premise beta has not received that yet, is that correct? Until the on-premise updates include the 2.17.0 update, this is not resolved. My company has blocked all remote access to SysAid at the firewall until this is resolved.



I hope SysAid prioritizes this critical update. It's been nearly a month since cloud customers received this.



Thanks,

Ben
Wen on-prem?
Hi EMartinez & Ben H,



We have been working fervently to get this ready for our On-prem accounts to support Apache Log4j 2.17.1, I hope to have news by beginning of next week about when it will be available.



Kind Regards,

Maayan



EMartinez
Wen on-prem?
Hi Ben,

Happy to update the On-Prem version is released and include Log4j fix (upgraded to Apache Log4j v2.17.1)!

it also include the mobile add-on and many more improvement check IT out:

→ Download SysAid 21.4 On-Prem Release ←

If you have any issues in upgrading the release, please reach to our Customer Care team via our Helpdesk or live chat

Let us know how it goes!

Cheers,

Maayan



PS - Heads up for the next OP release (v22.1), the End User Portal will sunset, take the time now and move your operations to the modern and more sophisticated cousin SysAid’s Self-Service Portal for better user experience and security standards.



Ben.H
Hi Maayan,



When will the on-premise customers receive the Log4j 2.17.0 update? Even the current on-premise beta has not received that yet, is that correct? Until the on-premise updates include the 2.17.0 update, this is not resolved. My company has blocked all remote access to SysAid at the firewall until this is resolved.



I hope SysAid prioritizes this critical update. It's been nearly a month since cloud customers received this.



Thanks,

Ben
NOTE for those upgrading their On-Prem version:

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”.
Thoughts about when the RDS service will be patched for Log4j? We use the cloud version of SysAid, but the RDS service runs on a local server and is continually flagged as being Log4j vulnerable. :-(



** As follow-up, it appears something had broken with the RDS service that caused it to be unable to update itself successfully. I had to uninstall and reinstall it and then, once it registered with the cloud, I was able to select update and it was successful in bringing the RDS up-to-date. I still had to go manually delete the old LOG4J JAR files after the update to stop the server from being flagged as vulnerable because the old JAR files were still hanging around. 😞 **



Thanks and have a blessed day!



Brandon.
Hi Brandon Haag,

Just to confirm did you follow the steps above to remove old library files? This should resolve the flagging issue

Let us know,

Thanks,

Maayan



Brandon Haag
Thoughts about when the RDS service will be patched for Log4j? We use the cloud version of SysAid, but the RDS service runs on a local server and is continually flagged as being Log4j vulnerable. :-(



** As follow-up, it appears something had broken with the RDS service that caused it to be unable to update itself successfully. I had to uninstall and reinstall it and then, once it registered with the cloud, I was able to select update and it was successful in bringing the RDS up-to-date. I still had to go manually delete the old LOG4J JAR files after the update to stop the server from being flagged as vulnerable because the old JAR files were still hanging around. 😞 **



Thanks and have a blessed day!



Brandon.
The vulnerable JAR files were not moved to a different folder when upgrading RDS, as instructions stated (unless I overlooked instructions specific to RDS). They were left in the same folder so they were easy to find. Also of note, apparently the upgrade process did not restart the RDS service, so it was still running in a vulnerable state after the upgrade completed. When I manually deleted the JAR files, it crashed the RDS service, but all was well once I stopped and restarted the service. Might be a good idea for future versions of the upgrade process to restart the service once an upgrade has been completed.



Hope this helps and have a blessed day!



Brandon.
Hi Brandon,

I opened a ticket on your behalf to further investigate this behaviour and see if this is something we can identify rout cause and address.

Cheers,

Maayan



Brandon Haag
The vulnerable JAR files were not moved to a different folder when upgrading RDS, as instructions stated (unless I overlooked instructions specific to RDS). They were left in the same folder so they were easy to find. Also of note, apparently the upgrade process did not restart the RDS service, so it was still running in a vulnerable state after the upgrade completed. When I manually deleted the JAR files, it crashed the RDS service, but all was well once I stopped and restarted the service. Might be a good idea for future versions of the upgrade process to restart the service once an upgrade has been completed.



Hope this helps and have a blessed day!



Brandon.

Reply


Terms & ConditionsCookie settings