Keycloak is NOT affected by the Log4j remote code injection vulnerability (CVE-2021-44228) #9078
Replies: 14 comments 40 replies
-
|
Is there any minimum version of Keycloak to be used which doesn't have this vulnerability? |
Beta Was this translation helpful? Give feedback.
-
|
Please see updated initial text from RedHat maintainer. |
Beta Was this translation helpful? Give feedback.
-
|
https://securityboulevard.com/2021/12/log4shell-jndi-injection-via-attackable-log4j/ Risk for 1.2.17 is moderate but still vulnerable apparently |
Beta Was this translation helpful? Give feedback.
-
|
The date mentioned "Update 13/12/2022" is incorrect and needs to be updated. |
Beta Was this translation helpful? Give feedback.
-
|
@ashishtchaudhari thanks, updated to the correct year ;) |
Beta Was this translation helpful? Give feedback.
-
|
@CmdrMichael |
Beta Was this translation helpful? Give feedback.
-
|
Glad to hear. What about the docker image provided, does it include log4j? |
Beta Was this translation helpful? Give feedback.
-
|
i started that noise before seeing this :-/ keycloak/keycloak-containers#344 as i read, containers just pull in tar.gz and configure... i confirmed in 13.0.1 that does indeed only reference the log4j api bits. i think this applies to at least >= 13.0.1 containers (not vuln). |
Beta Was this translation helpful? Give feedback.
-
|
CVE-2021-44228 is about log4j 2 (second generation of log4j), but Keycloak uses/has reference to log4j only - almost 10 years old release. |
Beta Was this translation helpful? Give feedback.
-
|
also possible w/ env var as mentioned in keycloak/keycloak-containers#344 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Is Keycloak using such a JMS Appender? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the links @daniel-beck but the post you link to has been updated again showing that 1.x could, if used a certain way, have the vulnerability. For the record, I trust the analysis of the Keycloak team saying it does not, and they did not use it that way. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
@MarkQuigley Still no reason to panic, see apache/logging-log4j2#608 (comment) Basically, don't let just anyone configure your logging system and you're fine. Seems orders of magnitude less important. |
Beta Was this translation helpful? Give feedback.
-
|
@daniel-beck agree to agree :-) |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Hey Guys, Thanks and Regards |
Beta Was this translation helpful? Give feedback.
-
|
The vulnerability is in log4j-core, not in the api |
Beta Was this translation helpful? Give feedback.
-
|
I checked this link: GHSA-jfh8-c2jp-5v3q and found that api was also mentioned with vulnerability. Thats why i was unsure about the usage. Thanks for the headsup. |
Beta Was this translation helpful? Give feedback.
-
|
are we sure that the vulnerability is only in log4j-core ? I do not see log4j-core on keycloak servers, but just want to make sure that Keycloak is not impacted by this vulenrability ? |
Beta Was this translation helpful? Give feedback.
-
|
@ashishtchaudhari the affected class is the JNDILookup class, which is part of log4j-core, not api. |
Beta Was this translation helpful? Give feedback.
-
|
Quoting from GHSA-jfh8-c2jp-5v3q:
|
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Does it make sense to remove the JMSAppender class from the |
Beta Was this translation helpful? Give feedback.
-
|
Does keycloak use the JMSAppender class by default ? |
Beta Was this translation helpful? Give feedback.
-
|
The JMSAppender issue is much less severe, and in reality shouldn't really be an issue:
As such I'm not planning any immediate fixes being released, and this particular case will most likely be handled by WildFly team in WF 16 I would hope. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like wildfly is affected by log4j2 vulnerability. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
WildFly is not affected as it does not include the JNDILookup. The JMSAppender issue in Log4j 1.x is handled as a separate CVE (CVE-2021-4104) and I would imagine WildFly team will come with some updates on that. However, it is far from as critical as jndi lookup strings are taken from config, not from user-input, and it should only be possible to load strings from jndi, not serialised objects. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you a lot! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, in our product we are using the keycloak docker image from https://hub.docker.com/r/jboss/keycloak (tag 8.0.1, yes I know this is VEERY old...). We are using it 'as is' with just some minor configurations. Are we safe with this version according to CVE-2021-44228? Would be great to have a confirmation as our customers currently urgently demand confirmations from us... Thanks for your feedback! Best Regards, Joerg Rohrschneider |
Beta Was this translation helpful? Give feedback.
-
|
a lot of hard work has been done by the community to help us all. see #9078 (reply in thread) specifically for version breakdown. |
Beta Was this translation helpful? Give feedback.
-
|
@StYerk42 You should be worried about other CVEs: https://www.cvedetails.com/vulnerability-list/vendor_id-25/product_id-46161/Redhat-Keycloak.html |
Beta Was this translation helpful? Give feedback.
-
|
@deadlysyn Thank you pointing to this list; I actually had seen the version in the pom.xml, but reading some other comments I was not sure if that is really the version used at runtime or if there might be another third-party tool using a later version... @rsousa That is definitely true; we know that we have a lot of work ahead of us updating our many third party libraries... But currently we need to address this specific vulnerability because it is in focus on customer's side. |
Beta Was this translation helpful? Give feedback.
-
|
for k8s mates, there is a great article from sysdig about mitigation measures - https://sysdig.com/blog/mitigating-log4j-kubernetes-network-policies/ |
Beta Was this translation helpful? Give feedback.
-
|
Is there any way to upgrade log4j 1.2.17 to log4j2 2.15? Or maybe some way to completely remove log4j if is not needed? |
Beta Was this translation helpful? Give feedback.
-
|
There are a number of issues in log4j v1.x:
An update of keycloak to a recent log4j version would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Both the first we've already comment on, and you can find more information in the linked blog post from WildFly. The SocketServer is not an issue in Keycloak, and it really is questionable if this should be marked as a CVE at all. SocketServer contains its own main method and is a test/util included in the Log4j 1 library that has to be started manually. Now, of course Log4j 1 shouldn't really include test/utils inside the main jars, but that doesn't make this a CVE. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Hi guys, We also use docker.io/jboss/keycloak:15.0.0 image.....in the container we can find the following .jars
Can you confirm that the these .jars are save and not affected? |
Beta Was this translation helpful? Give feedback.
-
|
Please read the above statement - this is already explained
|
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
I believe the official statement has been tested with the latest version of Wildfly and result in non exploitable. |
Beta Was this translation helpful? Give feedback.
-
|
Please update to a current version. It is close to irresponsible to run such an old version. |
Beta Was this translation helpful? Give feedback.
-
|
Lots of options but if you are on AWS and need to stand up a newer version quickly this can help: |
Beta Was this translation helpful? Give feedback.
-
|
a big thank you to all maintainers and contributers for addressing this urgent topic. very much appreciated and extremely helpful in identifying necessary tasks. thanks! |
Beta Was this translation helpful? Give feedback.
-
|
In case someone might be interested: I wrote a shell script to remove log4shell relevant classes from all log4j jars in the file system. https://stackoverflow.com/a/70362694/1948252 In this example the last file was readonly, thus the red notice. |
Beta Was this translation helpful? Give feedback.
-
|
Always nice with options, yahoo released one three days ago: https://github.com/yahoo/check-log4j |
Beta Was this translation helpful? Give feedback.
and others
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
Keycloak does not include the Log4j libraries that are affected by the recent remote code injection vulnerability, and for this reason is NOT affected by this vulnerability.
Even though the Log4j APIs are included, as separate log manager is used, which does not include the affected JNDI lookup capability.
Keycloak adapters do not include Log4j directly, but rather depend on what is available in the applicable application servers, so we do highly recommend that you review your applications to verify if they may be affected.
The same applies if you have customised Keycloak, and for some reason included additional Log4j dependencies in the distibution.
Update 20/12/2021
This topic has now been locked for further comments due to irrelevant comments. If you believe there is anything we are missing in our assessment of the Log4j issues please report it to keycloak-security@googlegroups.com and we'll assess it and update this announcement accordingly.
Update 14/12/2021
The WildFly team has published a great blog post summarising the impact of the Log4j security vulnerabilities for WildFly. In summary it validates our previous assessment for Keycloak, and neither WildFly or Keycloak are affected by CVE-2021-44228, or the related CVE-2021-4104 in Log4j 1.
The Quarkus team has also issued a statement that also validates the Keycloak.X Quarkus preview distribution is also not affected.
Update 13/12/2021
Keycloak includes only the Log4j API in the server distribution. Logging is handled by JBoss Logmanager, not Log4j directly. However, JBoss Logmanager does include some Log4j classes itself. There is currently two versions of JBoss Logmanager, the Log4j 2 version. The Log4j 2 version does NOT include the affected JNDILookup class. The Log4j 1 version is not affected by this particular CVE, but there is a related CVE (CVE-2021-4104) that is currently being investigated, which is less critical as the JMSAppender has to be explicitly enabled, does not take user-input for the JNDI lookup, and evidence suggests only strings and not classes can be loaded.
Recommendations:
As an additional note; reviewing the dependencies in Keycloak source code (pom.xml files) does not provide a correct an accurate view. An older version of Log4j is included, but only in test scope, and does not control what is included in the server distribution. Both the Keycloak server and adapters rely on logging libraries provided by the runtime (application server). In the future we are removing the WildFly server distribution, and will deprecate and/or extract adapters into a separate project, this will allow us to clean up the dependencies in the source code, to provide an accurate view.
Beta Was this translation helpful? Give feedback.
All reactions