CVE-2021-45046 for log4j - upgrade vended version soon?

[Anonymous]

Looks like our fix for jamf for our previous issue was not complete.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

https://logging.apache.org/log4j/2.x/security.html

[jrippy]

I noticed this as well.

[BCPeteo]

Wonder if we can still use 2.15.0 “This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).”

[spotmac]

@BCPeteo you can replace the class.  I replaced the class to 2.16

https://docs.jamf.com/technical-articles/Mitigating_the_Apache_Log4j_2_Vulnerability.html

[mbroxton]

@spotmacare you saying that you've replaced:

log4j-1.2-api-2.15.0.jar
log4j-api-2.15.0.jar
log4j-core-2.15.0.jar
log4j-slf4j-impl-2.15.0.jar

with

log4j-1.2-api-2.16.0.jar
log4j-api-2.16.0.jar
log4j-core-2.16.0.jar
log4j-slf4j-impl-2.16.0.jar

and Jamf Pro 10.34.1 still works?

[spotmac]

Yes, don’t forget to update the ownership of the files.

chown jamftomcat:jamftomcat file

[Anonymous]

I would be loathe to update the jar files provided by a vended product without them saying "Yeah, totally do that".

I am still learning jamf but I could see manually updating internals causing issues down the line when you want to upgrade. I don't know if jamf's installer/upgrader assesses existing files. Also, we are not sure WHAT files jamf may update on any one upgrade.

This just introduces technical debt your typical busy admin doesn't need unless they are impeccable documenters; and as much as I like documentation, it doesn't always happen.

[spotmac]

Jamf always updating (extracting ROOT.war) always all files and recovery the configuration files. 

The idea to replace the files comes from Jamf self 😉

https://docs.jamf.com/technical-articles/Mitigating_the_Apache_Log4j_2_Vulnerability.html

[Anonymous]

I missed that one. Thanks for pointing it out!

[mbroxton]

rmday, good point. Thank you for that.

spotmac, good point as well. Thank you.

I'm just weighing my options at this point. I'm already on version 10.34.1 which uses log4j-core-2.15.0.jar. So CVE-2021-44228 should be covered.

As for CVE-2021-45046, the official word from Jamf is this:

We are aware of CVE-2021-45046 that was remediated in log4j 2.16.0. Based on what we know today, this new vulnerability does not affect Jamf products. The conditions required for the exploitation of the vulnerability are not met by Jamf's use of the log4j library. We will continue to investigate and monitor, but no further action is required to remediate this CVE with Jamf products.

[mbroxton]

I just found this:

https://community.jamf.com/t5/jamf-pro/third-party-security-issue/m-p/253740

Looks like CVE-2021-45046 is not an issue.

[spotmac]

Keep in mind this: 

https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/

[mvanstone]

I agree with this, score went from 3.7 to a 9.0.

I'm running 10.34.1 with 2.15, hopefully they will just update to 2.16 to avoid any possible issues.

Hopefully soon!

[BCPeteo]

The jamf document (https://docs.jamf.com/technical-articles/Mitigating_the_Apache_Log4j_2_Vulnerability.html) says:

Download apache-log4j-2.15.0-bin.zip or later from the following webpage:

I just tested 2.16 and it seems fine

[mbroxton]

ostrowsp, I have overlooked the "or later" detail in the official doc. I will just go ahead and update to 2.16.0.

[Anonymous · Accepted solution]

The topic here is getting current coverage in this post from jamf folks:

https://community.jamf.com/t5/jamf-pro/third-party-security-issue/m-p/254389

I would move over there to contribute.