As many of you likely already know, a vulnerability in Java’s log4j logging protocol can potentially enable malicious actors to execute code on computers which are using it. As of this posting, many folks are scrambling to assess their risk and patch any vulnerability they have. This is a quick roundup of what is currently known about Infor CRM.The good news is that Infor CRM does not use this protocol, and is not vulnerable to this exploit. No action is needed on Infor CRM itself. However, the situation is less clear with some products commonly installed with CRM.
If you are using SQL 2019, there is a version of the log4j.jar file that is potentially vulnerable. SQL does not use they protocol by default, so it would only be called on if you had specifically configured SQL to use it. If, out of an abundance of caution, you wish to disable SQL’s ability to used this file, you can rename, effectively hiding it from SQL. In SQL 2019, you should look in the C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars folder. Find the file log4j-1.2.17.jar and rename it. log4j-1.2.17.old or log4j-1.2.17.bad are popular choices. I do not have easy access to more recent versions of SQL, so I cannot say if they contain a version of this file.
If you have Crystal Reports installed, it also many contain versions of this file. Checking SAP’s site, they claim that Business Objects in not vulnerable to this exploit. I am assuming this is a similar case to SQL, where the file exists in case someone want to make uses of it, but by default it is not used. Once again, you can be double sure the file will never be used by renaming it. Infor lists the files C:\Program Files (x86)\Business Objects\Common\3.5\java\lib\external\axis\1.3\log4j.jar and C:\Program Files (x86)\Business Objects\Common\3.5\java\lib\external\log4j.jar. Checking an installation I had access to, I found copies of log4j.jar at slightly different locations under the SAP Business Objects folder, and renamed those. Once again, these files would only be used if you had set the system up to use that sort of logging, and renaming them is just to make extra-sure that does not happen.
Infor also list locations those files are locating in Tibco Spotfire and Birst Cloud agent. I am not very familiar with either of those products, and do not have easy access to a system running them, but I include those locations at the end of the post, out of completeness. Generally speaking, whether Infor-related or not, the vulnerable file will called log4j.jar or log4j-[versioninfo].jar. If you go to the folder of a program you suspect in Program or Programs (x86), you can search for log4j.jar and log4j*.jar to see if the vulnerable file is present. You can effectively disable the file by renaming it, but keep in mind this can break programs that are actually using that logging (none of the ones mentioned here actually use it by default).
Tibco Spotfile file locations: C:\tibco\tss\6.5.0\tomcat\webapps\spotfire\WEB-INF\lib\log4j.jar , C:\tibco\tss\6.5.0\tools\lib\log4j.jar
Birst Cloud Agent file locations: C:\BirstCloudAgent\lib\log4j-1.2-api-2.11.1.jar , C:\BirstCloudAgent\lib\log4j-api-2.11.1.jar , C:\BirstCloudAgent\lib\log4j-core-2.11.1.jar , C:\BirstCloudAgent\lib\log4j-slf4j-impl-2.11.1.jar , C:\BirstCloudAgent\lib\log4j-slf4j-impl-2.11.1.jar