Jamf Pro Hotfix Release Coming Soon

[JenK]

A new hotfix release is coming soon for Jamf Pro 9.97.1488392992 (formerly Casper Suite). This release includes an important security fix and we recommend customers upgrade to the latest version as soon as possible. We will notify Jamf Pro customers via email and on Jamf Nation as soon as the hotfix release becomes available.

If you have any questions about this release or anything else, please do not hesitate to reach out.

[dmueller]

Hi @jen.kaplan, Is this specific to 9.97.x, or are all below versions affected (ie: 9.96 and below)?

Thanks

-Dennis

[JenK]

If you are currently using Jamf Pro 9.0 or higher, we strongly recommend you upgrade to this hotfix release.

[eng]

Jen,

Given that you've now warned people twice to upgrade, this seems serious. Does jamf plan on detailing the security vulnerability?

I would love to know what the issue was.

[brunerd]

Yeah.. is there a CVE on that? ;) I doubt it... Only a single one back in 2012:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4051
... then they asked the egghead who filed it, to never to do that again probably! ;> (pure conjecture)

Save yer old Tomcat ROOT folders, rig up script to compare every file from old and new... it'll be noisy as all hell I have to imagine... perhaps stat for file size change or changes of a certain size... that'd narrow down what changes... then diff or strings->diff and see if it is evident... whoever has time for that should do that (and is probably a student with lots of free time, or works at a Uni and has a free minute or two). Report your findings here and save us all time! ;D

[mostlikelee]

Will it force a client upgrade?

[mscottblake]

Some of us have Change Management to deal with. Can you confirm that the security details will be provided with the notification?

In my case, I have to get approval over 2 weeks before changes can be made, so the details of the security concern is crucial to a shortened approval process.

[PatrickD]

+1 for more info, and commenting to follow.

[davidhiggs]

related feature request here

[donmontalvo]

@davidhiggs voted up, thanks for pointing us to it.

[SeanA]

@davidhiggs voted up. Also thanks.

It seems Sales/Marketing has no problem being able to send emails to everyone.
Security does not have the same pull and so have to resort to forum?
ooookay.... I am really trying to figure out the methodology here.

[rderewianko]

I guess this is still incoming.. I don't see it in my jamf assets...

[JenK]

The 9.97.1488392992 hotfix release is now available. Per our initial post, this release includes an important security fix, and we recommend upgrading as soon as possible. Release notes and upgrade instructions will be sent directly to customers via email.

We plan to share more details on this security fix once we’ve given our customers time to upgrade to this release.

[jrwilcox]

We will not normally install until we have the details.

[RobertBasil]

Will this be auto installed for Cloud clients or do we have to schedule it?

[RobertHammen]

@jen.kaplan The issue here is that, in a lot of organizations, an upgrade like this, even a security hot fix, needs to be approved via change management. And one of the first things that needs to be provided in the change management process is WHAT EXACTLY this fixes. It's a classic chicken-and-egg problem.

I understand if it's a serious issue you want people to have the time to get the update applied before the information is disclosed. But, at the same time, you need to find a way to disclose the vulnerability to clients. Perhaps ask the clients to sign an NDA of some kind? Regardless, many folks are at an impasse and won't be applying the update until details are released.

[bvrooman]

The release notes do not call out relevant details about the vulnerability (CVE identifier, CVSS rating, etc.). All of that will determine how quickly we (and numerous other organizations) schedule this update, and what sort of resource priority the remediation effort will receive.

Obviously no one here is asking for sample exploit code, or anything that would be potentially damaging. Even a CVSS score would be something to go on.

[mm2270]

Going to chime in here as well. I cannot go thru my change management approval and just ask them to have faith that it fixes something serious, and eventually all will be known. Just give it a little while. This doesn't fly in many organizations. Frankly, I'm surprised folks at Jamf wouldn't already know this. We need to have some details on what the issue is so it can be properly assessed and steps can then be taken to install the hot fix. Not telling us until after we install it isn't acceptable.

I will gladly sign an NDA if needed to get the info up front. Just don't ask me to try to get approval to install this without knowing what the issue is it fixes.

[nwiseman]

I agree with everyone else here. I'm going to need more info if to get this appropriately pushed forward.

[donmontalvo]

Hot fixes have to go through Change Management process that includes going in front of a Change Advisory Board (CAB) to explain risk/fix.

NDAs exist for this reason, to provide us with the information we need to protect our client, while protecting Jamf's interests.

This is probably a process that needs to be vetted out on the Jamf side and that's totally reasonable.

Hopefully this happens sooner than later, so we don't expose our client to unnecessary risk.

Forwarding a link to this thread to the CAB stakeholders.

[bentoms]

At previous roles, I've had to push through emergency change requests from vendors in the same circumstances as what is here.

At current role, we're updating customer JSS's ASAP.

[donmontalvo]

Yep, the issue is "We need to apply a patch because the vendor says to" doesn't fly at Change Advisory Board (CAB) meetings. YMMV

[gachowski]

I think you guys might be looking at this the wrong way... While I agree transparency is important. You guys are trying get Jamf to disclose something that they feel they shouldn't.

Do your change control recommend the change and say that the vendor recommended the upgrade ASAP for not made public security reasons. If your change control approval group denies the change then that is on them.

C

PS The more I think about it, it's not really very cool for anyone to push Jamf to release details about the vulnerability.

[bentoms]

@donmontalvo has done at many orgs I've worked at. Read between the lines here & advise appropriately

@gachowski +1

[ryanstayloradob]

Is this a zero-day vulnerability? Has this vulnerability been in the product since version 9.0? We are going to test this first in our Stage environment.

[donmontalvo]

@gachowski it's not about being cool, it's about protecting our client.

NDA <-- that's what this is for (re: releasing to public)

We just received word Jamf is ramping up to provide the info we need.

[bentoms]

@ryanstayloradobe https://www.jamf.com/jamf-nation/discussions/23236/jamf-pro-hotfix-release-coming-soon#responseChild...

[johnmcnair]

@donmontalvo is correct.

Yep, the issue is "We need to apply a patch because the vendor says to" doesn't fly at Change Advisory Board (CAB) meetings. YMMV

At the company I provide ITO services for, the Change Advisory Board (CAB) is filled with people that have the technical skills/knowledge to ask the question: what does the update fix? If we do not answer these questions to their satisfaction, then the Change is denied. Forcing us to go back to Jamf with the questions that they "should" have provided upfront.

[bvrooman]

From our TAM...

... we will not be releasing any additional information until we have given customers time to upgrade to this release.

Looks like everyone is towing the company line. No responsible disclosure, no CVE, no severity rating.

[gachowski]

This is about trust. Either you trust Jamf or you don't.

If you change control group prevents the change then it's their issue. I am sure that Jamf did what they thought was best in a bad situation.

Us pressuring Jamf for more info is just wrong and I am betting even dangerous.

C

[bpavlov]

In case anyone has any feedback on how communication without putting customers at risk, perhaps you might want to upvote or share ideas here: https://www.jamf.com/jamf-nation/feature-requests/5842/better-discloure-of-hotfixes-concerning-secur...

[RobertHammen]

Going to strongly disagree with that. Information could be released (CVSS score, zero-day? general info) without providing info that may compromise JSSes. What MANY of us are trying to say is, Jamf merely saying "hey, here's an important hotfix update" is NOT ENOUGH INFO for us to move forward.

I totally understand why they won't publicly release the info, but they need to do more to meet us halfway.

[chris_kemp]

I have to chime in here with +1 for notifications. We have change management as well, not to mention that we are currently in a company-wide change freeze. I need to know at least something about the nature of what we're dealing with if I'm going to a) sell management on an exception, or b) put my @55 on the line by breaking the freeze. I get the need for secrecy, but OTOH we're paying customers, presumably responsible, and deserve to be informed about what it is we may or may not be installing in our environments.

[donmontalvo]

@gachowski wrote:

This is about trust. Either you trust Jamf or you don't.

Not sure I'd ever agree with that. :)

Trust is for neighbors and lawnmowers.

NDA is for risk management.

There's more to this than just security.

There's also the "Scream Test" avoidance factor. ;)

[mschroder]

Thanks for the heads-up. It would be useful to provide additional information like

• what is the risk
• are there ways to mitigate until the update can be installed

I appreciate having received an email with the announcement. But seeing URLs like "http://mkto-p0016.com/xyz" when doing a mouse-over on the links in the email does not increase the confidence in that email. Who is mkto-p0016.com? Why is it only http?

I feel there is room for improvement.

[rderewianko]

@mschroder mkto-p0016.com belongs to https://www.marketo.com/

[mschroder]

@rderewianko I thought so, but is that a reason to consider a http URL to that site sufficiently trustworthy to click on it to get an important security update?

[tlarkin]

Disclosures aside if a vendor releases a security patch that is not a scheduled release due to a vulnerability they are fixing, you should still be able to accomplish that in your Orgs. We have change management in place but if you've been in IT for more than a few years odds are you have had to do emergency patching in the past. Your process should allow for emergency patching.

If your process really halts you due to lack of disclosure I think you should maybe re-evaluate your process. We were able to get it tested in our test environments. Run our validation tests. Collect data and test some more, and then ship to production with in maybe half a day today.

While I am not excusing the lack of communication and disclosure I do understand that an unscheduled hotfix to patch a vulnerability is enough reason for me to run the patch through my environments, validate it is good, nothing else breaks and ship it to production. I honestly think if you have to go through a review board for change management you may want to re-evaluate your process, or streamline it where things don't take months or longer to deploy.

Given the fact a disclosure was not communicated clearly before or during the hotfix leads me to believe disclosure will happen later on after customers have had a chance to patch their environments. This was probably due to jamf wanting to mitigate people using the exploit. Leaving it unpatched because of unclear communication is not very responsible in my personal opinion. Whether you agree with this approach of disclosure or lack there of is a separate subject in my opinion over say ensuring the security of your Org. While I also want to hold every vendor to properly QA their products so new bugs aren't introduced in a patch/upgrade I also think your Org should do their own due diligence of testing.

I would like to see more disclosure on this and I would be okay with a security to security conversation where jamf can just disclose the issue to one of my security engineers and let my security handle it from there. However, I do think if you can't make a change, especially a change due to a patch for security you may want to re-evaluate the process you are currently stuck in.

[barnesaw]

Is it a big enough issue that I STILL haven't been notified by Jamf directly about this hotfix?

That doesn't inspire "trust" in Jamf.

[donmontalvo]

Putting aside personal preference and opinion, the simple fact is CAB exists to protect companies from disruption and subsequent financial loss from unnecessary changes. I'm very happy for folks who aren't burdened with this inconvenient reality. Really. I wish the rest of us had it that way. :)

With that said, I agree with those who are simply asking for enough details to push the hot-fix through the CAB process. We're not looking for in depth details that would enable bad hombres. We're looking for the base level information necessary to warrant applying any hot-fix. Of course NDA applies in these scenarios.

What we are trying to avoid is another "You guys really need to upgrade" advice from Jamf, and subsequent long threads about how the update/upgrade blew up in their faces (yes, even though carefully tested; you simply can't cover every possible scenario in a lab). You know, companies don't want to be a "Scream Test" for a product.

As long time customers, many have Encompass, we look forward to the point where Jamf matures/grows to the point where it can better accommodate the needs of stricter environments.

For the record, Jamf is the best product available for managing large numbers of Macs. It is manageable, sustainable, and fully supported.