Webswing versions since 2.6, including 2.7, 20.1, 20.2, 21.1 and 21.2 use Log4j 2 versions that are vulnerable to CVE-2021-44228.
Updated with information about CVE-2021-45046 and CVE-2021-45105
Description
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From Log4j 2.15.0, this behavior has been disabled by default.
Webswing versions with fix:
Followinf Log4J versions are used:
Webswing 2.6.20 - Log4J 2.16.0
Webswing 20.1.15 - Log4J 2.17.1
Webswing 20.2.14 - Log4J 2.17.1
Webswing 21.1.6 - Log4J 2.15.0
Webswing 21.2.6 - Log4J 2.17.1
If you need a fix for other version please contact us at support@webswing.org.
Depending on your SLA you should have access to and be eligible to use following version:
- Starter: 21.2.5 (current stable)
- Standard: +20.2.14 (current LTS), +2.6.* (LTS)
- Professional: +20.1.14 (extended support), +21.1.6 (extended support)
Mitigation without update of Webswing
All vulnerable Webswing version use log4j version 2.13.2. This means the easiest way to mitigate this vulnerability without upgrading Webswing is to add below system property to webswing.bat or webswing.sh start script.
For example:
java -Dlog4j2.formatMsgNoLookups=true -jar webswing.war ...
Webswing is using log4j also in session JVM, so it is important to add "-Dlog4j2.formatMsgNoLookups=true" system property to all application's vmArgs in webswing.config file as well.
Alternatively this vulnerability can be mitigated by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Another way is to substitute a non-vulnerable or empty implementation of the JndiLookup class, in a way that the classloader uses your replacement instead of the vulnerable version of the class.
In Webswing the log4j-core jar files are located inside the webswing-server.war, under WEB-INF/lib and WEB-INF/swing-lib folders.
This can be done using following script:
#!/bin/bash
WAR_ARCHIVE=$1
TMP_FOLDER=./log4shell-fixer-tmp
if [[ -d "$TMP_FOLDER" ]]; then
echo "please remove $TMP_FOLDER before continuing."
exit 1
fi
if [[ -f "$WAR_ARCHIVE" ]]; then
WORKING_DIR=`pwd`
mkdir $TMP_FOLDER
unzip -d $TMP_FOLDER $WAR_ARCHIVE `unzip -l $WAR_ARCHIVE |awk '/log4j-core-.*\.jar/{ print $4 }'|tr '\n' ' '`
find $TMP_FOLDER/ -iname '*.jar' -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;
cd $TMP_FOLDER
find . -iname '*.jar' -exec zip $WORKING_DIR/$WAR_ARCHIVE {} \;
cd $WORKING_DIR
rm -r $TMP_FOLDER
else
echo "File $WAR_ARCHIVE does not exist. Usage $0 <vulenrable.war>"
fi
Vulnerability inside client applications
Updating Webswing version does not automatically patch usage of vulnerable version of Log4j 2 library in client applications. If you are using a vulnerable version of Log4j 2 in your application code, please apply similar recommended steps to mitigate the vulnerability in your application code.
How do I test if my Webswing version is vulnerable?
The simplest way is to replace the root security module name in webswing config with a URL that will detect the vulnerability.
For example this is how webswing.config will look like:
{
"/" : {
"path" : "/",
"security" : {
"module" : "${jndi:ldap://localhost:1389/9e2ecd67-6c90-4777-8a61-d259953bc356}",
...
}
For detection URL you can start this tool: https://github.com/huntresslabs/log4shell-tester
(or use online version https://log4shell.huntress.com/ at your own risk)
When you start Webswing server with this setup, you will see this log in console:
2021-12-13 08:27:26,753 ERROR [main] (SecurityModuleWrapper.java:92) Failed to initialize security module.
java.lang.ClassNotFoundException: ${jndi:ldap://log4shell.huntress.com:1389/9e2ecd67-6c90-4777-8a61-d259953bc356}
at java.net.URLClassLoader.findClass(URLClassLoader.java:471) ~[?:?]
...
If you see a log appear in the log4shell-tester webpage, then your setup is vulnerable.
CVE-2021-45046, CVE-2021-45105
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105
Two new log4j Vulnerabilities have been identified that affect log4j version 2.16.0
Webswing is not affected by these as it does not use Context Lookup. Only logging configurations with a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}) are affected. Please check your log4j configuration.
More info here: https://logging.apache.org/log4j/2.x/security.html
CVE-2021-44832
Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832
Currently we plan to include an update to Log4J 2.17.1 in the standard monthly releases - beginning of January.
