Log4j and log4j2 library vulnerability
-
I'm not sure if you guys are tracking but unauthenticated RCE exploit just got dropped and is being exploited in the wild for log4j and log4j2 library.
This is used in a ton of products from apache struts to elasticsearch as the default logging framework.
Does cloudron use this and if so when can we get a patch? -
I'm not sure if you guys are tracking but unauthenticated RCE exploit just got dropped and is being exploited in the wild for log4j and log4j2 library.
This is used in a ton of products from apache struts to elasticsearch as the default logging framework.
Does cloudron use this and if so when can we get a patch?@staff
This is important.Cloudron tho runs mostly on java script.
I highly doubt Cloudron it self is affected in any way.Here some sources:
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
https://www.lunasec.io/docs/blog/log4j-zero-day/
And if you are more of a video type:
-
@staff
This is important.Cloudron tho runs mostly on java script.
I highly doubt Cloudron it self is affected in any way.Here some sources:
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
https://www.lunasec.io/docs/blog/log4j-zero-day/
And if you are more of a video type:
@brutalbirdie said in Lo4j and log4j2 library vulnerability:
Cloudron tho runs mostly on java script.
just to clarify, Java and Java Script are not the same, not even compatible
JavaScript is more for the web while Java is more for embedded system. -
Right so Cloudron as the platform is not affected by this as far as I understand. We don't use log4j(2).
With regards to apps which may potentially use it, I only found Metabase to be using it at least, but so far hard to tell how and if that is affected.
-
Ok so metabase and grafana packages are now updated to have a fix for this vulnerability.
Let us know if further apps I might have missed just now, also require fixes.
@nebulon awesome. Thank yall for hopping on this. This was huge.
-
Ok so metabase and grafana packages are now updated to have a fix for this vulnerability.
Let us know if further apps I might have missed just now, also require fixes.
@nebulon said in Lo4j and log4j2 library vulnerability:
Ok so metabase and grafana packages are now updated to have a fix for this vulnerability.
Let us know if further apps I might have missed just now, also require fixes.
Looks like Minecraft needs an update too:
@loudlemur said in Security: Log4shell:
There is a serious security problem with minecraft:
https://www.abc.net.au/news/2021-12-11/log4shell-techs-race-to-fix-software-flaw/100692876I don't know if this effects Cloudron's software, but it is already weaponized, apparently.
-
@nebulon said in Lo4j and log4j2 library vulnerability:
Ok so metabase and grafana packages are now updated to have a fix for this vulnerability.
Let us know if further apps I might have missed just now, also require fixes.
Looks like Minecraft needs an update too:
@loudlemur said in Security: Log4shell:
There is a serious security problem with minecraft:
https://www.abc.net.au/news/2021-12-11/log4shell-techs-race-to-fix-software-flaw/100692876I don't know if this effects Cloudron's software, but it is already weaponized, apparently.
@jdaviescoates Its heavily weaponized. Like if you have an app thats affected chances are its going to get popped if you leave it unmitigated. Broad array of actors are exploiting it.. from coin miners to more advanced threats. Grey noise is tracking the IP's associated with the threat campaigns and right now they are numerous.
-
@privsec I'm already receiving exploit/scan attempts inbound. No successful exploits. I believe nothing in my cloudron stack uses it. I can't find any confirmation nextcloud does. If you find something i'd love it asap.
-
B BrutalBirdie referenced this topic on
-
@privsec I tested nextcloud with a log4j2 testing tool from huntress and I couldn't get it to callback to the ldap server so i think its gtg.
-
@privsec I tested nextcloud with a log4j2 testing tool from huntress and I couldn't get it to callback to the ldap server so i think its gtg.
Here's a maintained list with log4j advisories: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
log4j detector: https://github.com/mergebase/log4j-detector
-
Here's a maintained list with log4j advisories: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
log4j detector: https://github.com/mergebase/log4j-detector
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
-
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
This tool is also neat, with or without cloudron context : https://github.com/fullhunt/log4j-scan
-
"Log4j 2.15.0 and previously suggested mitigations may not be enough" - https://isc.sans.edu/diary/Log4j+2.15.0+and+previously+suggested+mitigations+may+not+be+enough/28134
@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_ :-(
-
@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?
-
@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?
@nebulon The only SOLR instance is the Cloudron internal mail indexing, in my case.
-
@nebulon The only SOLR instance is the Cloudron internal mail indexing, in my case.