we are first busy with releasing 2021.12 (with Log4J 2.16) shortly after that the 2 LTS releases will be released (so beginning of Januari)
Hi Johan,
Can the just released Log4j 2.16 be a drop-in replacement for the version (I believe versions 2.11.2 up to 2.13) in Servoy 2019.x/2020.x/2021.x ?
We could then code sign everything again and deploy new WARs with jndi fully disabled.
Or are there incompatibles?
i think that should just work, because thats kind of what i did over all our branches, the only thing that really is different when generating a WAR in 2020.03_LTS before and after my change is that there are 4 updates jars…
And as far as i have tested now, the logging works fine after that.
I have a tomcat9 on Ubuntu with only command line access.
Where does the
-Dlog4j2.formatMsgNoLookups=true
go?
Thanks,
Christian
Hi Christian,
I don’t know about Debian/Ubuntu but on Centos I can add it to JAVA_OPTS in tomcat.conf (in /conf)
But that worked only for the one installed via the package manager.
If you got the package directly from apache.org you need to add it to catalina.sh in /bin.
Hope this helps.
What about Servoy 7 and https://cve.report/CVE-2021-4104 ?
Please an update on this one.
as that CVE says thats not default only when you have configured a special appander the JMSAppender, Servoy didn’t do that by default
Thanks Johan, I was looking for that confirmation.
After CVE-2021-44228 we now have a new related vulnerability CVE-2021-45046.
This last CVE shows that Log4j version 2.15 is still vulnerable with certain attack variants. Even with -Dlog4j2.formatMsgNoLookups=true .
So it seems really paramount that organisations need to start patching their servers with the latest Log4j 2.16 version, which disables the attack vector completely (jndi is disabled by default).
So to summarise the situation:
- Updating your JVM to a specific version doesn’t help. Log4j 2.x in every JVM version is vulnerable.
- setting -Dlog4j2.formatMsgNoLookups=true will NOT block all attack variants
- log4j 2.15 is still vulnerable, update to version 2.16.
So if you run any recent version of Servoy (8.4 and up) you can replace the log4j jars with the latest ones from apache.org
If you use SmartClient you still need to code sign these jars, for Web- and NgClient deployments this is not really necessary.
The InfoSec community is reporting that after coin miners and malware to make your server be part of botnets (Mirai and others) they now see that attackers are loading ransomware and remote access tools .
@servoy maybe you need to send out an updated adviserary email.
On a lighter note. Today I learned that Log4j is pronounced ‘Log Forge’, not ‘Log Four Jay’ or any other variation.
Maybe we should rename ServoyForge to Servoy4j
On an even lighter note (but is it really?) I leave you with this (credit):
[attachment=0]IMG_4825.JPG[/attachment]
If i read it all correctly i don’t think this latest one really affects us.
Because it is related to MDC lookups, and to be clear yes Servoy does use them this is our default pattern:
But those 2 are not user defined inputs a user can’t set the values of that by there own thing. These are all fixed servoy controlled values.
There is maybe a possible scenario where a user could influence the output because we also add this, if it is set, to MDC: if (username != null) MDC.put(“username”, username);
so if a user makes a username with a jndi lookup string and the pattern will expand that, which we don’t do by default in our pattern, so the pattern doesn’t have $${servoy:username:-} but i think if that is added it could potentially do a lookup
ah i think even username is fine because we use our own lookup class for that so we have our own: https://logging.apache.org/log4j/2.x/ma … okups.html (thats the servoy: in front of that name)
So that shouldn’t be doing a jndi lookup, except if it works somehow reclusively, that’s something i need to test so for example have the $${servoy:username}} in the pattern
and the value of the username is the: $${env:USER} what does it print there…
Hi Johan,
that is a lot of 'if’s and (don’t) thinks and 'maybe’s
A couple of questions: Which Servoy versions are you going to update to the latest Log4j 2.16 version? and when?
And in case we can’t update to a newer Servoy server: Can we conclude that the best way to mitigate this is to remove the jndilookup classin the log4j-core.jar file?
here is also some more deeply info: https://www.lunasec.io/docs/blog/log4j- … 021-45046/
we will be releasing 2021.03.2 LTS and 2021.12 both very likely this month
and early next month 2020.03.X LTS
Thats all our current branches that are then on 2.16 of Log4J
But yes you can just patch the jar your self and remove that class.
Or patch the generated WAR and override the 4 log4j jars with 2.16 version of all 4 of them
jcompagner:
Or patch the generated WAR and override the 4 log4j jars with 2.16 version of all 4 of them
Hi Johan,
any further instructions on this?
I removed
log4j-api.jar
log4j-core.jar
log4j-slf4j-impl.jar
log4j-web-2.xxx.jar
and replaced with version 2.16
So same names, except log4j-web-2.16.0.jar
Servoy launches without a problem, but it seems like it doesn’t log anything
Only find this to be an issue in deployed solution by the way.
Developer works fine.
jcompagner:
ah i think even username is fine because we use our own lookup class for that so we have our own: https://logging.apache.org/log4j/2.x/ma … okups.html (thats the servoy: in front of that name)
So that shouldn’t be doing a jndi lookup, except if it works somehow reclusively, that’s something i need to test so for example have the $${servoy:username}} in the pattern
and the value of the username is the: $${env:USER} what does it print there…
right tested this and yes it is recursively so if you use $${servoy:username}} in your log pattern (so you changed the default) you can be affected by this if the user could type in a username that does lookups
i tested it with:
‘${env:USER} ${env:PATH} ${java:os}’ (as my username, so that string feeded into security.login(username))
and that USER doesn’t print (its prints just $env:USER because i guess it can’t find something)
but the other 2 really prints the resolved stuff (so my full path of the first and the second is “Windows 10 10.0, architecture: amd64-64”)
mboegem:
jcompagner:
Or patch the generated WAR and override the 4 log4j jars with 2.16 version of all 4 of themHi Johan,
any further instructions on this?
I removed
log4j-api.jar
log4j-core.jar
log4j-slf4j-impl.jar
log4j-web-2.xxx.jarand replaced with version 2.16
So same names, except log4j-web-2.16.0.jarServoy launches without a problem, but it seems like it doesn’t log anything
Only find this to be an issue in deployed solution by the way.
Developer works fine.
i think i did the same
what i did was deployed a WAR of 2021.09 (generated by that)
i run that in tomcat, everything seems fine i see logging
then i turn of tomcat and what i did was jsut adjust the extracted dir of the war so for me that was:
C:\javatools\apache-tomcat-9.0.40\webapps\listformcomponent\WEB-INF\lib
i deleted there 4 files
then i took the 4 new files (i took them from a WAR i generated from a new install that has the new ones)
and placed them in that dir
then i restarted tomcat, and everything seems to work fine, logging is working nicely
ok internally we also could reproduce this the problem is the log4j-slf4j-impl.jar that is taken…
don’t take this one: https://mvnrepository.com/artifact/org. … mpl/2.16.0
but take this one: https://mvnrepository.com/artifact/org. … mpl/2.16.0
so with the “18” in the name
else you miss services that kick starts everything.
Could someone please post the correct method to secure a Linux/Ubuntu server that is using normal Tomcat install with Servoy WARs. (there was a note for Windows service…)??
I have a few client production servers running
Apache Tomcat/9.0.xx
on
11.0.11+9-Ubuntu-0ubuntu2.20.xx
and would like to make sure they are secure, if possible?
Thanks
Rafi
Is it possible for Servoy, to just publish a zip-file with the jars we need to replace in Servoy versions 2020/2021?
(I believe all version up until 2021.9 use the same log4j version)
It it isn’t possible on the forum, then maybe a separate repository on Servoy GitHub?
IMHO this vulnerability issue is way to important to neglect, so clear instructions would be much appreciated by the whole community.