Log4j and log4j2 library vulnerability
-
Docker Scan should allow us to scan cloudron containers if any doubt remains :
https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/edit : https://github.com/docker/scan-cli-plugin/releases/tag/v0.11.0
-
@girish I ran https://github.com/mergebase/log4j-detector today and it seems that at least SOLR is vulnerable(?)
/proc/5961/task/9300/cwd/lib/ext/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-( /var/lib/docker/overlay2/32ab0d12f3342918d0ffea4a1392cb760f852f9bf0a219c682dd366ff26e72bc/diff/usr/share/java/log4j-1.2-1.2.17.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-| /var/lib/docker/overlay2/5bb4ce30d32c6760fe21e98ab6f98651bf9591e83ab2385f0a4833ee5ef0c979/diff/app/code/solr/contrib/prometheus-exporter/lib/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-( /var/lib/docker/overlay2/5bb4ce30d32c6760fe21e98ab6f98651bf9591e83ab2385f0a4833ee5ef0c979/diff/app/code/solr/server/lib/ext/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-( /var/lib/docker/overlay2/f8ed382cc2590afd6189335f84aaf0f561811a5165dbf58191be61048c5312f5/merged/app/code/solr/contrib/prometheus-exporter/lib/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-( /var/lib/docker/overlay2/f8ed382cc2590afd6189335f84aaf0f561811a5165dbf58191be61048c5312f5/merged/app/code/solr/server/lib/ext/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
-
@nebulon ping
Can you check that out? -
@brutalbirdie just because the library is used, does not mean the app is actually vulnerable. In either case all we can really do from our side is to closely track upstream releases during such times and release new app packages asap. We usually can't really patch the upstream apps easily. In this case it seem to be prometheus related? @necrevistonnezr do you know to which app those layers in your case are related to?
-
@necrevistonnezr ah ok, then this is fine. It is not exposed or anything.
-
I am aware of solr being detected by the static analyzers (the marketplace images complain about the same). solr is used internally for full text search in the mail container. It's not on by default and it's also not exposed outside the internal docker network (so not exposed to outside world).
Still, we will update the mail container. Solr only put out a new release yesterday which update log4j.
-
@mastadamus I'm happy to report that Crowdsec successfully responded to a log4j exploit scanner. If you set up your nginx log configuration per my post in support, and install the nginx collection as well as the log4j2 collection with an firewall iptable bouncer it will auto block any ip belonging to an attempt it parses out.
crowdsec crowdsecurity/apache_log4j2_cve-2021-44228 Ip 45.83.65.33 2021-12-17 07:55:25 2021-12-17 07:55:25
-
@mastadamus do you have a step by step instructions to setup crowdsec in a cloudron context ?
-
-
@mastadamus thanks alot, will try to implement this & will report under your post
-
@nebulon I found log4j2 libary usage in kutt (urlshortener)
Standard config:
# ONLY NEEDED FOR MIGRATION !!1! # Neo4j database credential details NEO4J_DB_URI=bolt://localhost NEO4J_DB_USERNAME= NEO4J_DB_PASSWORD=
changed to this without errors:
# ONLY NEEDED FOR MIGRATION !!1! # Neo4j database credential details #NEO4J_DB_URI=bolt://localhost #NEO4J_DB_USERNAME=neo4j #NEO4J_DB_PASSWORD=BjEphmupAf1D5pDD
Is there anything else to do?
Is that even a issue?