Servoy Forum

Posted: **Wed Dec 15, 2021 8:43 pm**

Does anyone know if the WAR files produced by the Servoy Cloud Control Center have the updated JAR files within them? If so, is it for all Servoy versions or only some?

Thanks
Steve

Posted: **Wed Dec 15, 2021 8:46 pm**

I have been doing some testing and this is what I came up with;

You need to download the v2.16 binaries of Log4j (LogForge) here.
When you unzip the archive you will find a a lot of jars in there. You need to pick out the following 4 jars. I suggest you put them in a separate directory.

log4j-api-2.16.0.jar
log4j-core-2.16.0.jar
log4j-slf4j18-impl-2.16.0.jar <-- the '18' part is important
log4j-web-2.16.0.jar

So far I can see these jars are only used on the server so code-signing is not needed for SmartClient deployments.

You can now update your developer OR you can update any deployed WAR files. I will explain each scenario here below:

Updating Developer
Go into the application_server/lib directory of your developer installation. Make sure Developer is not running.
If you are on macOS and you have the Servoy.app bundle then you first need to right-click on the app and select Show Package Contents. Then the path is Contents/application_server/lib .
Identify the 4 log4j-*.jar files and remove those. Then copy in the 4 new jars listed above. Don't overwrite them as they are named differently.
Now you can launch Developer and export a new WAR file for your deployments.

Updating existing WAR deployment
Shutdown your WAR context that you are going to update via the Tomcat Manager interface.
Connect to your server and go into the <tomcat-dir>/webapps directory. Here you see all your WAR files and expanded directories.
Navigate into <war-directory-name>/WEB-INF/lib .
Identify the 4 log4j-*.jar files and remove those. Then copy in the 4 new jars listed above. Don't overwrite them as they are named differently.
You can now start the WAR context again via the Tomcat Manager interface.
You can check in the <tomcat-dir>/work/Catalina/localhost/<war-name>/ if there are cached files. If so you might want to delete those, just for good measure. If you do then you also need to restart Tomcat.
Please be aware that if you touch the original *.war file your changes will be overwritten and the original log4j version will be loaded :!:

Updating your *.war file
Your .war file is just a zip file with another file extension so you can use tools like BetterZip (macOS), 7-zip (Windows) or unzip on Linux (CLI) to unarchive the WAR file.
Navigate into <war-directory-name>/WEB-INF/lib .
Identify the 4 log4j-*.jar files and remove those. Then copy in the 4 new jars listed above. Don't overwrite them as they are named differently.
Now zip the directory back up and make sure it has a .war extension again.
Now you can deploy the war file to your servers.

Hope this helps.

Posted: **Wed Dec 15, 2021 8:50 pm**

Thanks Robert - those instructions are very clear and extremely helpful.

You are a star as always!

Posted: **Wed Dec 15, 2021 8:51 pm**

ROCLASI wrote:Hi Johan,

jcompagner wrote:but take this one: https://mvnrepository.com/artifact/org. ... mpl/2.16.0

so with the "18" in the name

So we need to use log4j-slf4j18-impl-2.16.0.jar instead of log4j-slf4j-impl-2.16.0.jar to replace the existing log4j-slf4j-impl.jar. Correct?

And for absolute clarity. Servoy also comes with slf4j-api.jar and slf4j-jdk14.jar.
We don't have to update those, correct?

you have 4 log4j jars in a developer install (or in a WAR/WEB-INF/lib)

: log4j.png (9.97 KiB) Viewed 28886 times

if you update those 4 jars in a developer install then creating a WAR from that will include those

those 4 jars need to be all replaced with the 2.16.0 variants and be sure that the log4j-slf4j-impl.jar is really the one with the 18 in the name (so don't pick exactly that same jar from a log4j download)

overwrite 3 files and remove the log4j-web-2.11.2.jar (and add the log4j-web-2.16.0.jar in its place)

Posted: **Wed Dec 15, 2021 9:05 pm**

Hi Steve,

Yes we did patch again all branches yesterday with the new log4j patch and nightly images were generated. So you have to take the nightly snapshot to get it. Otherwise, you'll have to do the patching yourself (with replacing the jars and all)

Hope this helps.

Best,
Sean

Posted: **Wed Dec 15, 2021 9:08 pm**

Thanks Sean - so to confirm, if we are building the WAR with the nightly build we are fine but if we are using any of the other versions to build we need to patch manually?

Thanks
Steve

Posted: **Wed Dec 15, 2021 9:34 pm**

Hi Steve,

Well you asked about ServoyCloud images. For those you have three options

NIGHTLY: This is master branch - 2022.3
NIGHTLY-LTS: This is current LTS - 2021.3.x LTS
NIGHTLY-RELEASE: This is current RC - 2021.12 RCx

For non-servoy cloud users, you can also pickup the distributions at
https://build.servoy.com/latest/

Hope this helps.

Best,
Sean

Posted: **Thu Dec 16, 2021 2:00 am**

I follow the instructions to replace the log4j files and when I try to launch the admin page after restarting he service I get the following traceback. I tried undoing the change I previously made to wrapper.conf but still get the same error. I put the old files back in and the server starts fine. Do the new jars need to be renamed to match the names of the old jars?
Here is my version info:
Servoy version 2019.12.1 -releaseNumber 3543
java.version=1.8.0_301

HTTP Status 500 - Error instantiating servlet class com.servoy.j2db.server.servlets.ConfigServlet
type Exception report

message Error instantiating servlet class com.servoy.j2db.server.servlets.ConfigServlet

description The server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Error instantiating servlet class com.servoy.j2db.server.servlets.ConfigServlet
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:591)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Unknown Source)
root cause

java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/Filter
java.lang.Class.getDeclaredConstructors0(Native Method)
java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
java.lang.Class.getConstructor0(Unknown Source)
java.lang.Class.newInstance(Unknown Source)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:591)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Unknown Source)
root cause

java.lang.ClassNotFoundException: org.apache.logging.log4j.core.Filter
java.net.URLClassLoader.findClass(Unknown Source)
java.lang.ClassLoader.loadClass(Unknown Source)
sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
java.lang.ClassLoader.loadClass(Unknown Source)
java.lang.Class.getDeclaredConstructors0(Native Method)
java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
java.lang.Class.getConstructor0(Unknown Source)
java.lang.Class.newInstance(Unknown Source)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:591)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Unknown Source)
note The full stack trace of the root cause is available in the Apache Tomcat/8.5.9 logs.

Apache Tomcat/8.5.9

Posted: **Thu Dec 16, 2021 2:08 am**

Just for fun, I went ahead and renamed the 2.16.0 jar files to have the same names as the original jar files and my server starts up fine with the new versions. Am I safe or am I doing something wrong? Is the additional parameter wrapper.java.additional.xx=-Dlog4j2.formatMsgNoLookups=true still required even if we are using the 2.16.0 log4j jars?

Posted: **Thu Dec 16, 2021 2:19 am**

Hi Steve,

The name of the file should not be an issue.
I have updated like 10 WARs already and never had an issue.
Perhaps you have cached files in your <tomcat>/work directory ?

Posted: **Thu Dec 16, 2021 2:33 am**

I pulled the entire <tomcat>/work directory out, replaced my renamed jars with the new ones as named and tried again, but the same error occurs.
When you say the name of the file should not be an issue, does that mean the name shouldn't be causing the error or that it is not a problem if I rename the files?
Here is a screenshot of the directory just to make sure I am using the correct files:

: Screen Shot 2021-12-15 at 4.26.36 PM.png (51.8 KiB) Viewed 28841 times

Posted: **Thu Dec 16, 2021 10:36 am**

i think Steve uses the wrapper.conf that means our legacy application server (so not WAR) and then yes be sure to have the same names, else you need to change it everywhere (including in wrapper.conf and so on)

Posted: **Thu Dec 16, 2021 11:44 am**

Robert and Marc,

Many thanks for your efforts to help the Servoy Community regarding fixing the log4j exploits!

Regards,

Posted: **Thu Dec 16, 2021 1:13 pm**

Thanks also from my side to the Servoy community for the support!

I am still not clear about the following. I see in my Developer as well as in the WAR Deployment (both Servoy v2020.3.2) the 5 following "log4j" files. These are:
- log4j.jar
- log4j-api.jar
- log4j-core.jar
- log4j-slf4j-impl.jar
- log4j-web-2.11.2.jar

What about the file "log4j.jar"? Doesn't this need to be replaced?

Posted: **Thu Dec 16, 2021 1:21 pm**

there should not be a log4j.jar

it could be that that is a old left over form many upgrades.

if you look into that log4j.jar/META-INF/manifest.mf
what does the contents of that manifest.mf say what version it is? i guess 1.2?

Servoy Forum

Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues

Re: Log4j issues