Third-Party Security Issue

[Aaron_Kiemele]

Update 12/28

On December 9, 2021, a Remote Code Execution (RCE) vulnerability (CVE-2021-44228) was identified in the log4j library (https://www.lunasec.io/docs/blog/log4j-zero-day/). The log4j project released version 2.15 to address this issue. New information has come to light identifying ways to exploit log4j 2.15 when the formatMsgNoLookups parameter was not set. CVE-2021-45046 was assigned to this and fixed on December 16, 2021 in log4j 2.16. 

We have continued to assess the impact and mitigate the vulnerability across our platform (tracked as PI-010403) as the security community has identified new issues in log4j. 

Due to the nature of these issues, these are considered critical vulnerabilities.

What Jamf products are impacted by the log4j vulnerability?

Jamf Pro (hosted on-premises): Patched

• Jamf Pro versions older than 10.31 do not use log4j 2.x (which these vulnerabilities pertain to). However, there are other known security issues that have previously been documented against these versions. We suggest strongly that you update to the latest release.
• The Jamf Pro 10.34.1 release mitigates the initial CVE-2021-44228. To mitigate the latest CVE, customers using 10.34.1 must set the “formatMsgNoLookups=true” parameter as described here. 
• We released Jamf Pro 10.34.2 to include log4j 2.16 and mitigate all currently known log4j vulnerabilities. No further configuration changes are necessary with this release.

We strongly encourage everyone running Jamf Pro on-premises to update to 10.34.2 or follow the manual instructions above as soon as possible.

Jamf Pro (Jamf Cloud and Jamf Cloud Premium): Mitigated and Patched

• Customers utilizing our cloud-based products have had the vulnerability mitigated through layered security controls, including disabling the vulnerable feature across all Java Virtual Machine instances using the formatMsgNoLookups=true parameter value and ensuring only secure message lookup patterns are in use. We are confident that our mitigations are effective against all currently known attacks.
• However, out of an abundance of caution, we are also upgrading all Jamf Cloud customers to 10.34.2 as quickly as possible. If you are a Jamf Premium Cloud customer, your environment has mitigations in place to protect you from these vulnerabilities. However, if you have a need to update to log4j 2.16, you can contact Customer Success and schedule your upgrade to 10.34.2 at your convenience. 

Jamf Connect: Not affected

Jamf Connect does not use the affected libraries.

Jamf Now: Not affected

Jamf Now does not use the affected libraries.

Jamf Protect: Not affected

Jamf Protect does not use the affected libraries.

Jamf School: Not affected

Jamf School does not use the affected libraries.

Jamf Threat Defense: Not affected

Jamf Threat Defense does not use the affected libraries.

Jamf Data Policy: Not affected

Jamf Data Policy does not use the affected libraries.

Jamf Private Access: Not affected

Jamf Private Access does not use the affected libraries.

Health Care Listener: Not vulnerable

While Health Care Listener does utilize the library that includes the vulnerability, it cannot be exploited by an attacker. Healthcare Listener 2.2.2 assets containing the updated version of Log4j 2.17 are available for download on Jamf Account.

Jamf Infrastructure Manager: Not vulnerable

While Jamf Infrastructure Manager does utilize the library that includes the vulnerability, it cannot be exploited by an attacker. Jamf Infrastructure Manager 2.2.2 assets containing the updated version of Log4j 2.17 are available for download on Jamf Account.

Next Steps

On December 17, 2021, we released Jamf Pro 10.34.2 to address the vulnerability. For more information on what’s included in this release, review the release announcement on Jamf Nation or read the release notes here. 

If you cannot upgrade to this latest release, you can choose to manually update the log4j instances of the affected systems as described in our technical documenta.... If you choose to implement the manual workaround as described, future updates (to versions after 10.34.2) will not be affected. For assistance with this workaround, reach out to support@jamf.com. 

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.

UPDATE 12/28

We are aware of CVE-2021-44832 that was remediated in log4j 2.17.1. Based on public disclosures to date, this vulnerability does not 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. We will continue to monitor the situation and will report on new information as it becomes available.

If you have any questions, please reach out to Customer Success for assistance. 

[Anonymous]

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=C08...

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

[Aaron_Kiemele]

The main post above has been updated.   4/17

[bradtchapman]

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.  

[Aaron_Kiemele]

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

[Aaron_Kiemele]

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

[R_C]

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?

[jrippy]

@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.

[Alitejawi]

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? 

[R_C]

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

[dmueller]

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

[Aaron_Kiemele]

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.

[seabash]

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.

[dkmansion]

Since it's not updated here yet.  Healthcare Listener and Infrastructure Manager applications have been updated with Log4j 2.17 and should be available in your product assets in your account if you use it. 
The New HCL/JIM version is 2.2.2.
Happy patching.

[jmahlman]

My cyber team is wondering if we can update the lo4j library to 2.17 manually (so it can be removed from scans). Will this work?

[Alitejawi]

Yes, you can do that, that's what I have done as well. I followed this, but replaced 2.16.0 for 2.17.0: https://docs.jamf.com/technical-articles/Mitigating_the_Apache_Log4j_2_Vulnerability.html

Worked perfectly fine. 

[Daphney]

Great work thank you for sharing this information.

myccpay account

[Aaron_Kiemele · Accepted solution]

UPDATE 12/28

We are aware of CVE-2021-44832 that was remediated in log4j 2.17.1. Based on public disclosures to date, this vulnerability does not 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. We will continue to monitor the situation and will report on new information as it becomes available.

[MrP]

Do you even work for JAMF?  How do we know this is credible information???

Paul

President of the United Federation, because my signature says so.

[AJPinto]

Aaron Kiemele is JAMFs Chief Information Security Officer. However I totally agree. There should be some kind of badge of some sort so we know this is a JAMF employee.

He did sign one of his posts 2 weeks ago in this thread, looks like it was originally an email. Not a source of trust by any means but it is what it is. I do find it funny a Chief Information Security Officer feels no need to prove his information is trustworthy. Suppose typical ivory tower nonsense and no one under him has the courage to tell him he is doing this wrong. We should have gotten these communications in emails.

[dkmansion]

True. I did get a notice from my internal JAMF customer support contact, wh pointed me to his/this thread when I was asking for info two weeks ago. For what it's worth [from me as another unknown person in the community 😉 ]

I agree staff should be easily identifiable when they post though.

Donald


IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is strictly prohibited. Thank you for your cooperation.

[Aaron_Kiemele]

Thank you, this is a good point. I will look into how we might best improve.  

Any ambiguous information can also be authenticated via the release notes here, by contacting your Customer Success rep, or reaching out to support@jamf.com

Aaron Kiemele
Chief Information Security Officer, Jamf

[MrP]

Our IAs aren't going to accept "New Contributor III" as an official source of information.  Until this is in a KB, or you provide proof of your claimed credentials, I have asked customer support for the information in an verifiable authentic manner.

[CalleyO]

Hello Jamf Nation! Community Moderator, Calley here. Thank you for raising the concern about identifying our Jamf employees in our Jamf Nation Community. Today we began rolling out the employee role badge next to a Jamf employee's name. However, this is a rollout, so not every Jamf will have a badge today, and we appreciate your patience as we work toward this goal. In the meantime, if you do have questions regarding any community members' status, please reach out via DM, Slack me on MacAdmin, or email at jamfnation@jamf.com.