Sounds like this may not be the end of the story. Looks like as of Monday 2.15.0 was found to not fully patch the vulnerability in all configuration.

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

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

@R_C  As 2.16.0 does not resolve any issues we are aware of, I would not recommend straying off the recommended workflow. 

It goes both ways.  Your security team would not be happy if Jamf asked it to disclose the "appropriate security controls" used to prevent access to your network, would they?

Can you elaborate on these conditions? I know our security group would want context. Can you help us out? Esp if further down you are NOT recommending the manual update here(but to 2.16):

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

Adding this blog post:

https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/

This is what was changed in 2.16.0 and what Jamf is not using and why it won't effect Jamf Services.
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

For customers that are Government Contractors CISA is REQUIRING companies be patched to 2.16 no later than 12/24 It would be great if jamf would patch the installers to accommodate for this, I realize this can be done manually but it will have to be done each time the JSS is upgraded.

https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

Summary

Note: CISA will continue to update this webpage as well as our community-sourced GitHub repository as we have further guidance to impart and additional vendor information to provide.

CISA and its partners, through the Joint Cyber Defense Collaborative, are responding to active, widespread exploitation of a critical remote code execution (RCE) vulnerability (CVE-2021-44228) in Apache’s Log4j software library, versions 2.0-beta9 to 2.14.1, known as "Log4Shell." Log4j is very broadly used in a variety of consumer and enterprise services, websites, and applications—as well as in operational technology products—to log security and performance information. An unauthenticated remote actor could exploit this vulnerability to take control of an affected system.

• On December 10, 2021, Apache released Log4j version 2.15.0 in a security update to address the CVE-2021-44228 vulnerability.
• (Updated December 15, 2021) On December 13, 2021, Apache released Log4j version 2.16.0 in a security update to address the CVE-2021-45046 vulnerability. A remote attacker can exploit this second Log4j vulnerability to cause a denial-of-service (DOS) condition in certain non-default configurations.
  • Note: affected organizations that have already upgraded to Log4j 2.15.0 will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046.

In order for these vulnerabilities to be remediated in products and services that use affected versions of Log4j, the maintainers of those products and services must implement these security updates. Users of such products and services should refer to the vendors of these products/services for security updates. Given the severity of the vulnerabilities and the likelihood of an increase in exploitation by sophisticated cyber threat actors, CISA urges vendors and users to take the following actions. 

• Vendors
  • (Updated December 15, 2021) Immediately identify, mitigate, and update affected products using Log4j to version 2.16.0. Note: as stated above, affected organizations will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046.
  • Inform your end users of products that contain these vulnerabilities and strongly urge them to prioritize software updates.
• Affected Organizations
  • In addition to the immediate actions detailed in the box above, review CISA's GitHub repository for a list of affected vendor information and apply software updates as soon as they are available. See Actions for Organizations Running Products with Log4j below for additional guidance. Note: CISA has added CVE-2021-44228 to the Known Exploited Vulnerabilities Catalog, which was created according to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities. In accordance with BOD 22-01, federal civilian executive branch agencies must mitigate CVE-2021-44228 by December 24, 2021. 

Question: How to check, if a Jamf Pro (Windows) server is already affected by active use of the Log4j vulnerability?

Would you see some suspicious entries in Jamf or Apache logs?

If Jamf Services are not affected by the changes in 2.16.0 then there is no reason not to include 2.16.0 instead of 2.15.0 in the release asap.

Aaron_Kiemele Is it possible to put a DATE on your UPDATE as we can't see if it was posted BEFORE or AFTER the last reply in this thread

THX

Great point, thank you. I will correct going forward. 

I think we need a clear announcement on the status of the newer CVE especially in light of the following:

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

and

https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

and the fact that it is encouraged that EACH customer makes a support ticket to jamf?

https://macadmins.slack.com/archives/C083RF51D/p1639753806150600?thread_ts=1639738070.128800&cid=C083RF51D

That seems like death-by-1000-papercuts to you...

The main post above has been updated.   4/17

Thanks.  Just got my email from Jamf about 10.34.2.  FYI: find + replace "lib4j" in your top post with "log4j" - it's in the bullet point just before the list of services.  

Thank you Jamf Nation for your understanding and patience. Throughout the last week we have been monitoring the log4j vulnerability situation around the clock and the risk involved has changed numerous times. I want to give you more transparency into our process and communications strategy. 

First, the original issue reported under CVE-2021-44228 was rapidly mitigated for Jamf Cloud and Jamf Pro 10.34.1 addressed on-premises customers with log4j 2.15.0. We strongly urged on-prem customers to upgrade, but made it clear that hosted customers were safe.

Jamf has not found any impact to the security of Jamf cloud-hosted platforms. We are confident the remediations put in place for CVE-2021-44228, including disabling the vulnerable feature via the  “formatMsgNoLookups=true” parameter combined with effective detection and web application firewall (WAF) rules, are sufficient to remove the risk.

On Wednesday there was a follow-up vulnerability identified under CVE-2021-45046. This risk was lower with a 3.7/10 score, but it continued to receive a great deal of attention. Log4j 2.16.0 was released to address this new issue. CVE-2021-45046 likewise was not applicable to Jamf due to our use of secure pattern layout configuration, but innovation around the exploit continued and the risk was upgraded to 9/10.

Jamf began incorporating this new version into the upcoming Jamf Pro 10.35 release. While there are workarounds that helped mitigate risks, many corporations and government institutions required 2.16.0 without exception. Our engineers and the Apache foundation both advised that the best position was an immediate upgrade regardless of other mitigative actions. Further details are documented here:  https://logging.apache.org/log4j/2.x/security.html

These issues, combined with reports of additional remote code execution (RCE) risks inherent in Log4j 2.15 now scored as a critical risk, combined with threat intelligence suggesting widespread research and exploitation across malicious actors, APT groups, and nation states is cause for concern. As of today, we strongly believe our cloud-hosted customers are not vulnerable to this attack. As we progress through the holidays, we made the decision in an abundance of caution and with our customers’ security in mind, to roll Log4j 2.16 out across all platforms as quickly as possible. This included shipping Jamf Pro 10.34.2 which incorporates log4j 2.16 for our on-prem customers. Due to the potential urgent security risk, we were unable to follow our typical communication process. We apologize for any inconvenience this may have caused. 

Your security remains Jamf’s top priority. We hope these actions help ensure you have a quiet holiday going forward. We will remain vigilant as new information becomes available and will make you aware.

Aaron Kiemele
Chief Information Security Officer, Jamf

@bradtchapman Thank you. Both security and copyediting are team sports.

FYI. V2.17.0 just dropped to address a CVE in v2.16.0

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

Log4j: the gift that keeps giving...

Anyone have bets on the table for the next CVE pushing us to v2.18.0?

Apache Log4j 2.17.0 has been released. Has there been any updates with regards to having this version available to be either manually installed or streamed into a new version of Jamf Pro? 

I just followed the prior Manual Remediation Guidance and used the v2.17.0 version of Log4j instead of v2.16.0.

Looks like it worked.

I would suggest backing up your Database both before and after the update, just to be on the safe side.

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

It looks like yet another release as more vulnerabilities have been discovered with the updates..later on 12/17.

v2.17..

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

UPDATE 12/18

We are aware of CVE-2021-45105 that was remediated in log4j 2.17.0. At this time, this new vulnerability does not seem to affect any Jamf products or services. The conditions required for the exploitation of the vulnerability are not met by Jamf's use of the log4j library. No further action is required at this time.

@Aaron_Kiemele While I know you are continuously busy tracking down threats, thank you for addressing this, giving us a little peak behind the curtain, and trying to be more open with information to the community.  We appreciate it.

Thanks for weighing in about v2.17.0 as pertains to Jamf’s usage of log4j.

Any chance this detail can be added to the official Jamf technical article Mitigating the Apache Log4j 2 Vulnerability

Also, does your team anticipate any disruption to Jamf Pro (on-prem) services, should an admin replace v2.16.0 w/ v2.17.0?

I’ll give it a whirl in non-prod env, but wanted to hear whether official Jamf engs were aware of any functional issues.

Do you have documentation from Jamf or some report stating it is not impacted?

Edit: Just googled you and realized you are the CISO. I'm leaving my question up because you really need a badge stating your position with Jamf. By just looking at your profile it looks like you are a random person off the street. Your job title should be under your name, not this "New Contributor III."