Servoy Forum

what does the contents of that manifest.mf say what version it is? i guess 1.2?

Manifest-Version: 1.0
Application-Name: log4j.jar
Bundle-Description: Apache Log4j 1.2
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-SymbolicName: log4j
Built-By: cy
Bnd-LastModified: 1336302107501
Bundle-ManifestVersion: 2
...

right so that is a 1.2 version
servoy itself doesn't use that anymore, so not sure if you have other 3rd party plugins that still do need this.
But anyway you can leave that one.

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

Hi Steve,

Added a general improvement that all war files build in Servoy Cloud are upgraded to 2.16.0 log4j jar files.
So even when you now build a 2021.09 or 2021.06 or older you have log4j 2.16.0

I'm running 2020.3 wondering about the 3 jar files (apparent duplicates) in developer/plugins:

org.apache.logging.log4j.api_2.12.1.jar
org.apache.logging.log4j.core_2.12.1.jar
org.apache.logging.slf4j18-impl_2.12.1.jar

My IT dept requested these be removed or replaced (along w/ the 2.12 jar in application_server/lib). So I'm focused on trying to do that and still have Developer run.
If I remove or replace, developer doesn't run. As described by others, I have updated the four 2.16 jar files in application_server/lib.

Though my IT dept may be being overly cautious, is there something I can do? Renaming 2.16 files to exactly match old names didn't seem to work in this case.

i don't think that is possible. you can't update your developer like that.
Renaming is also not working because i think eclipse doesn't look at the file names like that, but really looks into the manifest version and the whole developer expects that specific version in its configuration)

i guess the best patch for the developer is just to remove the jndi lookup class: org/apache/logging/log4j/core/lookup/JndiLookup from the log4j.core jar

Hi Rene

rvanveen wrote:Added a general improvement that all war files build in Servoy Cloud are upgraded to 2.16.0 log4j jar files.
So even when you now build a 2021.09 or 2021.06 or older you have log4j 2.16.0

That's excellent news thanks. Can you confirm that is already in place as the WAR we built and downloaded this morning still has the log4j files with the old names. Are these the new files that have been renamed?

Thanks
Steve

the story continues!

https://www.bleepingcomputer.com/news/s ... ixing-dos/

Yep, Log4j 2.17 is out, fixing a DoS vulnerability.

Also Blumira’s security team discovered the potential for an alternative attack vector in the Log4j vulnerability, which relies on a Javascript WebSocket connection to trigger the RCE on internal and locally exposed unpatched Log4j applications.
It effectively means that after your internet facing services you now should also patch your services on your local network, even your own machine.

ROCLASI wrote:
Also Blumira’s security team discovered the potential for an alternative attack vector in the Log4j vulnerability, which relies on a Javascript WebSocket connection to trigger the RCE on internal and locally exposed unpatched Log4j applications.
It effectively means that after your internet facing services you now should also patch your services on your local network, even your own machine.

that last part was already know for 2.15 therefor came 2.16. Now in 2.16 there is still a DoS vulnerability. in certain non default configurations

Harjo wrote:

ROCLASI wrote:
Also Blumira’s security team discovered the potential for an alternative attack vector in the Log4j vulnerability, which relies on a Javascript WebSocket connection to trigger the RCE on internal and locally exposed unpatched Log4j applications.
It effectively means that after your internet facing services you now should also patch your services on your local network, even your own machine.

that last part was already know for 2.15 therefor came 2.16. Now in 2.16 there is still a DoS vulnerability. in certain non default configurations

What Blumira’s is reporting on is an attack vector for pre 2.17 versions. They effectively say that if you are browsing the web on your computer a malicious website can use Websockets to connect/exploit any services on your local machine and local network.
It's an attack vector for services that are not directly accessible from the internet.
So patching these services with version 2.17 will mitigate this.

Will Servoy update the different Servoy versions to log4j 2.17?

lwjwillemsen wrote:Will Servoy update the different Servoy versions to log4j 2.17?

viewtopic.php?f=16&t=23399

our LTS release that we released yesterday already had 2.17
The same will happen for he final of 2021.12

LTS release has still 2.17, right? 2.17 is also not secure.

yes but that is only a problem for a specific configuration problem and then also really only when an attacker can make a change to the log4j configuration file and injects a very specific JDBCAppender
If an attacker can do that you already have other problems....

for the next release we did update it to 2.17.1 (just as 2021.12.x also is already using 2.17.1)

Thanks for the information.
Good to know. I'm already on 2.17.1 and a colleague of mine saw that the LTS is still using an older version. So I wanted to ask because other companies might find it interesting to know.

Johan, please have a look into Jira regarding my webclient problem