Servoy Forum

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:

<PatternLayout pattern="%d %p [%t] %c - %m [$${servoy:clientid:-} $${servoy:solution:-}]%n" />

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 wrote: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 wrote: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 wrote:

jcompagner wrote: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.

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.

+10 Thanks Mark.

We are struggling for hours with log4j jar-files for S2020.03 and cant get it to work...

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?

Hi Rafi,

rafig wrote: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

As I explained here there is really only one mitigation and that is updating your WAR file.
So Tomcat version, Java version or OS vendor/version is no longer relevant. The solution is the same for all.

Hi Robert,

ROCLASI wrote:Hi Rafi,
As I explained here there is really only one mitigation and that is updating your WAR file.
So Tomcat version, Java version or OS vendor/version is no longer relevant. The solution is the same for all.

Thanks, I did see that, but I'm hoping that Servoy can come up with an (easy?) method to help us all address this issue for our live clients?

rafig wrote:Hi Robert,
Thanks, I did see that, but I'm hoping that Servoy can come up with an (easy?) method to help us all address this issue for our live clients?

I guess the 'easy' route would be if Servoy put out updates so you can update your developer, export new WAR files and deploy. Which is about the same amount of work as replacing the jars, and replacing the jars also works on unsupported versions.