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.
Yeah.. is there a CVE on that? ;) I doubt it... Only a single one back in 2012:
... 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
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.
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.
@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.
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.
Forwarding a link to this thread to the CAB stakeholders.
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.
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 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.
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...
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.
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.
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. ;)
Thanks for the heads-up. It would be useful to provide additional information like
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.
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.
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.