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

Thanks

-Dennis

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

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.

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

Will it force a client upgrade?

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.

+1 for more info, and commenting to follow.

related feature request here

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

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

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

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.

We will not normally install until we have the details.

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

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

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.

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.

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

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.

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.

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

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.

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

@gachowski +1

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.

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