New day, new hole.
C’mon…
Best Christmas gift ever 
1 Like
From URL in the first post
Updated @ December 10th, 10am PST
Affected Apache log4j2 Versions
2.0 <= Apache log4j <= 2.14.1
CentOS seems to have… not log4j 2, which should be the affected version, but only log4j
Source
https://centos.pkgs.org/7/centos-x86_64/log4j-1.2.17-16.el7_4.noarch.rpm.html
I knocked on NethServer 7 installation with Webtop5, which should rely on Java, one way or another, and could take advantage of having log4j apache installed; output of rpm -qa log4j is empty. The installation i checked does not have @mrmarkuz or @stephdl repository installed, As far as i can remember.
Tomorrow i will check other installations, one with Zabbix and another one with Zammad.
4 Likes
Guacamole uses the not affected centos 7 log4j.
2 Likes
Thanks for your output, @saitobenkei.
This comes from the server i asked in my previous post.
*I was trying to post the output of rpm -qa from the same installation, but the post become “too big” for discourse (34k chars instead of 32) *
Installation is quite fresh (less than 6 months), these are the modules instlalled.
and yum autoremove is not… ready to cut something out.
Reminder: CentOS 7 should not install log4j2, but only log4j, which is present in some installs.
On one server I have Nextcloud, Mattermost and Webtop installed and the package is not there.
On the present one I had round cube (which I removed) and webtop and that’s it.
Only on this installation I have geolocation enabled on webtop.
Could this be related to this?
Honestly I dont think so.
I have several NS instances running, but none of them have log4j installed. At least, I am not getting any response after rpm -qa log4j
So I presume my servers are ok towards this vulnerability.
NethServer Version: 7.9
Hello
German Goverment BSI send a ZeroDay in the Java log pac Log4J. External (java?) code can run directly. Sever and services had to be stop or seperated.
Did Nethserver or application uses Log4j
Sorry German
same at me, but:
# locate -A log4j
/var/lib/tomcats/webtop/conf/log4j.properties
Proxmox seems have log4j2 installed, but as long as no interface is exposeed to the internet and it’s version 2.15.0 it should not be affected. So I think this isn’t a problem.
root@pve:~# apt list | grep log4j2
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
liblog4j2-java/stable-security 2.15.0-1~deb11u1 all
Stay save and healthy! (your installations and yourself 
)
2 Likes
The only Java application officially supported is WebTop.
WebTop does not use log4j directly, but log4j is a dependencies of another library.
Also, nor WebTop nor Tomcat8 includes log4j as bundles.
So, in the end, WebTop is not affected.
As correctly reported by @pike, also CentOS version of log4j is not affected.
Thanks to @gabriele_bulfon and @matteo.albinola do the analysis.
4 Likes
When I do a locate command for log4j and log4j2 I get a response for log4j because I used to have onlyoffice running. Locate command for log4j2 does not get a response.
[root@ns7 ~]# locate -A log4j2
[root@ns7 ~]# locate -A log4j
/etc/onlyoffice/documentserver/log4js
/etc/onlyoffice/documentserver/log4js/development.json
/etc/onlyoffice/documentserver/log4js/production.json
/var/www/onlyoffice/documentserver/server/Common/config/log4js
However, I did remove onlyoffice from nextcloud. Looks like the document server is still there and running…
1 Like
Ok, it seems that the library had been installed with tomcat 7, in fact on that machine I had problems because suddenly Webtop didn’t work anymore and there were two instances of tomcat running: 7 and 8.
Probably a version change was made during a webtop upgrade that didn’t work, since the server was installed using only the official packages.
[root@mail ~]# yum deplist log4j-1.2.17-16.el7_4.noarch
Loaded plugins: changelog, nethserver_events
package: log4j.noarch 1.2.17-16.el7_4
dependency: /bin/sh
provider: bash.x86_64 4.2.46-35.el7_9
dependency: java >= 1.5
provider: java-1.8.0-openjdk.x86_64 1:1.8.0.312.b07-1.el7_9
provider: java-1.8.0-openjdk.i686 1:1.8.0.312.b07-1.el7_9
provider: java-1.7.0-openjdk.x86_64 1:1.7.0.261-2.6.22.2.el7_8
dependency: jpackage-utils
provider: javapackages-tools.noarch 3.4.1-11.el7
dependency: mvn(javax.mail:mail)
provider: javamail.noarch 1.4.6-8.el7
dependency: mvn(org.apache.geronimo.specs:geronimo-jms_1.1_spec)
provider: geronimo-jms.noarch 1.1.1-19.el7
[root@mail ~]# yum --noplugins remove log4j-1.2.17-16.el7_4.noarch
Resolving Dependencies
--> Running transaction check
---> Package log4j.noarch 0:1.2.17-16.el7_4 will be erased
--> Processing Dependency: log4j for package: avalon-framework-4.3-10.el7.noarch
--> Processing Dependency: mvn(log4j:log4j) for package: apache-commons-logging-1.1.2-7.el7.noarch
--> Running transaction check
---> Package apache-commons-logging.noarch 0:1.1.2-7.el7 will be erased
--> Processing Dependency: apache-commons-logging for package: tomcat-7.0.76-16.el7_9.noarch
---> Package avalon-framework.noarch 0:4.3-10.el7 will be erased
--> Processing Dependency: avalon-framework >= 4.1.4 for package: avalon-logkit-2.1-14.el7.noarch
--> Running transaction check
---> Package avalon-logkit.noarch 0:2.1-14.el7 will be erased
---> Package tomcat.noarch 0:7.0.76-16.el7_9 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
log4j noarch 1.2.17-16.el7_4 @nh-updates 506 k
Removing for dependencies:
apache-commons-logging noarch 1.1.2-7.el7 @nh-base 181 k
avalon-framework noarch 4.3-10.el7 @nh-base 106 k
avalon-logkit noarch 2.1-14.el7 @nh-base 96 k
tomcat noarch 7.0.76-16.el7_9 @nh-updates 303 k
Transaction Summary
================================================================================
Remove 1 Package (+4 Dependent packages)
Installed size: 1.2 M
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Erasing : tomcat-7.0.76-16.el7_9.noarch 1/5
Erasing : apache-commons-logging-1.1.2-7.el7.noarch 2/5
Erasing : avalon-logkit-2.1-14.el7.noarch 3/5
Erasing : avalon-framework-4.3-10.el7.noarch 4/5
Erasing : log4j-1.2.17-16.el7_4.noarch 5/5
Verifying : log4j-1.2.17-16.el7_4.noarch 1/5
Verifying : avalon-framework-4.3-10.el7.noarch 2/5
Verifying : apache-commons-logging-1.1.2-7.el7.noarch 3/5
Verifying : tomcat-7.0.76-16.el7_9.noarch 4/5
Verifying : avalon-logkit-2.1-14.el7.noarch 5/5
Removed:
log4j.noarch 0:1.2.17-16.el7_4
Dependency Removed:
apache-commons-logging.noarch 0:1.1.2-7.el7
avalon-framework.noarch 0:4.3-10.el7
avalon-logkit.noarch 0:2.1-14.el7
tomcat.noarch 0:7.0.76-16.el7_9
Complete!
3 Likes
Savapage includes log4j: (thanks to @thorsten)
/opt/savapage/server/lib/log4j.properties.template
/opt/savapage/server/lib/web/log4j-1.2.17.jar
/opt/savapage/server/lib/web/slf4j-log4j12-1.7.30.jar
/opt/savapage/server/lib/log4j.properties
/opt/savapage/client/app/lib/log4j-1.2.17.jar
/opt/savapage/client/app/lib/slf4j-log4j12-1.7.30.jar
3 Likes
At Github you can find a log4j detector. It detects affected versions.
You can call it with:
java -jar log4j-detector-2021.12.13.jar
3 Likes
Also came across this https://github.com/jerrinot/log4shell-ldap not sure of the difference but thought I’d post Incase useful to someone
1 Like
According to McAfee
https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/
Update 12/14/2021
It has been confirmed that Log4j version 1.2 is vulnerable to similar attacks through the JMSAppender component and has been issued CVE-2021-4104. It is important to note this is not as easily exploitable as version 2.x. For exploitation to occur, JMSAppender must be enabled, and set with TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests. This is not the default configuration.
Sources
2 Likes
I tested two NS servers I administrate. One very basic (mail stack, NS, Sogo), the other same but more loaded with more or less experimental stuff.
-- Analyzing paths (could take a long time).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
-- No vulnerable Log4J 2.x samples found in supplied paths: [/]
-- Congratulations, the supplied paths are not vulnerable to CVE-2021-44228 ! :-)
1 Like