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.

[tlarkin]

the simple fact is CAB exists to protect companies from disruption and subsequent financial loss from unnecessary changes

If you don't patch security holes though, you are setting yourself up for disruption and possible financial loss. I totally get the whole do your own due diligence to mitigate risks and protect stake holders and I support that. I just think if it takes you a month to patch something that is too big of a risk to take is all.

At the very least you should still send this to your change board with the information that this is for a major security patch. If they decide not to move you at least did your job and communicated the risk. While jamf did not come out and quantify the risk the fact that it was an unscheduled release to fix a security hole means it is significant in my personal opinion.

[donmontalvo]

@tlarkin wrote:

it is significant in my personal opinion.

You just validated the reason CAB exists. :)

[mscottblake]

I have to agree with @tlarkin on this one. Any good CAB will have a process for this type of thing. Generally speaking, I need to request a change over 2 weeks beforehand, but we also have an emergency procedure for just this type of release; an unplanned vendor supplied security release.

This is highly irregular for Jamf. I would recommend that if you haven't already patched your systems, you do so soon. If your CAB is blocking you, make sure you put forth the effort to get things patched so that when the vulnerability details are released and it's as bad as I think it is, you can hopefully amend your processes to be able to address this scenario.

[donmontalvo]

I think there are two (or more?) scenarios...

1. You are at a company that doesn't have strict CAB processes (meaning exceptions are given).
2. You are at a company that has stricter CAB process, where even emergency changes require vetting/rating, where there is a minimum info baseline for vetting. (*)

(*)"Apply this fix, because we say so." <-- For #2 this will get you laughed out of CAB, and you may be assigned an action item to get the necessary info. While this thread shines a light on that, the real communication is happening offline, directly with the vendor, and may involve an NDA.

CAB covers any change, not just hot-fixes. Any notion that folks in scenario #2 can "just change the process" to get a vague hot-fix applied may be a bit of woolly thinking.

[bentoms]

@donmontalvo "minimum baseline for vetting" could be that "vendor advised this security update is needed, it's sever enough that they have mentioned on their public forum that thy will only disclose why once a large perecentage of folks have applied the patch" (with a link to Jen's posts here).

To add to the above, the hotfix will also be vetted by being installed in test.. before applying to prod. So you have the vendor strongly advising you to apply the hotfix & you've tested on your inf before rasing the request.

If this doesn't work.. wait it out. Hope this is not something that puts your orgs at massive risk & is exploited, honestly. And if/when jamf does advise, don't moan.. just apply the hotfix & go via your processes.

[donmontalvo]

@bentoms wrote:

@donmontalvo "minimum baseline for vetting" could be that "vendor advised this security update is needed, it's sever enough that they have mentioned on their public forum that thy will only disclose why once a large perecentage of folks have applied the patch" (with a link to Jen's posts here).

For those in scenario #2, that would fall under "getting laughed out of CAB".

As mentioned, you're just going to get kicked back for more info, which Jamf needs to provide.

If this doesn't work.. wait it out.

That's a good way to get fired, and possible become unemployable. ;)

Hope this is not something that puts your orgs at massive risk & is exploited, honestly.

Yep, that's kind of why this thread exists, the missing context is putting customers in scenario #2 at unnecessarily higher risk than is acceptable.

And if/when jamf does advise, don't moan.. just apply the hotfix & go via your processes.

When Jamf advises, the CAB will have the missing context needed for approval.

Then, hopefully next time a better process will be in place to accommodate customers in scenario #2.

[bentoms]

@donmontalvo I'vet been on a many CAB's, & have been in this situation with vendors before.

I've yet been "laughed out of CAB" for doing my job by installing a patch, on vendors advisement due to a vulnerability that is not at the time of CAB disclosed.

And, historically, it's been the right thing to do the apply the patch.

Yesterday I patched all of our MSP customers JSS's, no issues seen. Went well & as smooth as testing in our various test environments went.

[PatrickD]

I totally understand Jamf not wanting to release too much information on this to mitigate risk, however I think people here and CABs would be satisfied with the same level of disclosure as Apple with this sort of thing. It doesn't have to specific, just enough for an org to mitigate the risk with other controls whilst going through a testing, CAB and patching process.

i.e Risk: Possibility of remote root access to the JSS Response: Lockdown all remote access to the JSS with Firewall/s whilst testing is being carried out to validate patch.

This is not the case though. We don't know if it is a client or server vulnerability or how severe.

This is still vague yet gives you enough to go on, even if it didn't have the CVE ref.

[donmontalvo]

@bentoms I'm very happy that your CAB process experience has been so smooth. Really. I truly am. :)

@PatrickD posted:

This is exactly the type of context we are looking for. When Apple releases security updates, CAB uses this type of info to vet/rate. Kudos for posting the example.

Jamf are probably discussing it internally now, and I'm confident their process will be more accommodating in the future.

Study material for Jamf...

Apple Security Updates
Microsoft Security Bulletins
Adobe | Security Bulletins and Advisories
Mozilla Foundation Security Advisories
Google Chrome | Security Fixes and Rewards
Oracle | Critical Patch Updates, Security Alerts and Third Party Bulletin
Citrix | Support Knowledge Center
McAfee | Product Security Bulletins
Symantec | Security Updates

[bentoms]

@PatrickD & @donmontalvo I wonder if this conversation is conflating things.

I really hope that, folks are doing the update & are able to put it through their CAB. But that the discussions are more in regards to better process next time.

[donmontalvo]

Jamf definitely needs a better process.

[bvrooman]

There's a lot of "if your process is different from mine, it's wrong" in this thread. Maybe that's the case; maybe companies that adhere to a strict ITIL change process are actually exposing themselves to increased or undue risk. Regardless, if a company is large enough or strict enough to enforce that kind of process, then the odds of "one of those Mac people" leading some sort of revolution against the process – especially in a timeframe short enough to make a difference for this patch – is quite slim.

For example: our CAB meets regularly to approve scheduled changes, but we have an emergency process for 0-day patches, major performance issues, etc., and an after-the-fact process for production outages. Since I didn't have enough information to present this as a 0-day with a high CVSS, or even enough that I could "guess" at a standard severity rating, I couldn't put this through eCAB; it'll have to be scheduled at some point in the future (after-hours, since it can't be classified as an emergency) and put through for normal CAB approval at the next meeting.

If Jamf were to come to their senses, follow the industry practice, and disclose even the small amount of information in @PatrickD's example, then I'd happily submit this as an emergency change and get our systems secured.

The process I just described is absolutely not unique. I would venture a guess that most of the people in this thread who are calling for responsible disclosure are in similar situations; we can still patch this, but if we want to do outside of a scheduled window, we have to receive the same information that CABs have come to expect from security advisories in the rest of the industry.

[barnesaw]

Still haven't received an actual notification from Jamf about this. Despite a post about the release being available. All the CAB-centered discussion doesn't change the fact that Jamf sucks at customer-facing communication. Absolutely terrible.

[CasperSally]

I agree it's strange there's been no email if this is so high priority. My only guess is they want to see how the first few installs went for those quick to upgrade (and then maybe not suggest windows JSS users use the windows installer).

[bvrooman]

Perhaps ironically, my notification email came in at 3:19PM last Friday.

[barnesaw]

Also ironically, my comments are now moderated.

[barnesaw]

I got about 20 emails from Jamf, starting 4 months before my renewal, telling me to start that. Not a word about a "critical" security update, approaching 72 hours since release.

There's your priorities.

[donmontalvo]

@bvrooman wrote:

There's a lot of "if your process is different from mine, it's wrong" in this thread.

+1

[neilmartin83]

It's not ITIL that's necessarily the problem, it's how organisations interpret and implement it. ITIL has suggested process for changes like this, under "emergency changes".

Still had to do some paperwork in my case but the fact that Jamf had released this fix whilst stating it was important and should be applied ASAP was good enough to get it approved quickly, but did need some due diligence on my part to show I'd tested it and considered a back-out plan should we need to roll back. Citing other orgs and MSPs that patched over the weekend in response to this also helped.

[RobertHammen]

Still haven't received an email either.

[donmontalvo]

@neil.martin83 wrote:

It's not ITIL that's necessarily the problem, it's how organisations interpret and implement it. ITIL has suggested process for changes like this, under "emergency changes".

Spot on.

[bvrooman]

@barnesaw wrote:

my comments are now moderated.

This is deeply concerning. I realize this is Jamf's message board, and their product, and I further acknowledge that some in this conversation have been getting a little heated (probably myself included). However, is this an appropriate reaction to good-faith feedback?

[emily]

I got the email about it for our JamfCloud instance (that we migrated away from in November but they still have running) … :thinking_face:

[RobertHammen]

Jamf reached out and informed me that an email was sent but rejected by my US .gov agency's spam filters. Since I know more than just us haven't received the email, I suspect this happened to a lot of people. The email was sent around 3PM Central time from notifications@jamf.com, so if you haven't received an email, you might want to check any spam filtering/appliance.

[donmontalvo]

@RobertHammen wrote:

Jamf reached out and informed me that an email was sent but rejected by my US .gov agency's spam filters. Since I know more than just us haven't received the email, I suspect this happened to a lot of people. The email was sent around 3PM Central time from notifications@jamf.com, so if you haven't received an email, you might want to check any spam filtering/appliance.

All jokes aside, this is AWESOME news!

Not the SPAM filter issue...but that Jamf are actively pushing for the CVE.

Jamf rocks!

[millersc]

...but that Jamf are actively pushing for the CVE.

There was no CVE information. It read just like Jen's original post.

[mm2270]

@donmontalvo

but that Jamf are actively pushing for the CVE.

Per @jen.kaplan's post above:

Release notes and upgrade instructions will be sent directly to customers via email.

It was always Jamf's plan to send out emails to let clients know they should upgrade as soon as possible, but as far as I know, the actual details of the issue are still forthcoming and will likely not happen until they give it some unknown amount of time to let customers upgrade. I don't think anything specific has changed here.

BTW, still waiting for my email. I guess I'll need to check our spam system to see if something got caught in limbo.

[emily]

This is the email I got for our Jamfcloud instance that we no longer use. It came in March 2nd, 2017, at 12:45pm CT. I never got one for our self-hosted instance. In this case it's not a spam filter issue, as the Jamfcloud notification came in just fine from notifications@jamf.com.

[db_sw]

Do we need to follow any special instructions for the install? I don't see anything specific in the release notes for this patch's install process.

[AdamHWilliams]

We just upgraded our dev environment. Our JSS is on Windows. It blew away our Tomcat configuration and reset everything including our SSL certs. When we try and login (either with a JSS account or a domain account) we get logged out immediately. Have reached out to Jamf Support but so far nothing. I'd rather not roll back to a previous release if we can help it.

[CasperSally]

Jamf should take down the windows installer. how many of these posts are there now? sheesh.

[neilmartin83]

Going from 9.97 to 9.97.1482356336 and then 9.97.1482356336 to 9.97.1488392992 (what a mouthful), the Windows installer does not upgrade properly.

The giveaway is that the installer moans about ports 8443 and 8080 being open (unless you've changed your JSS so it isn't using the standard ports). You end up with 2 entries in the Control Panel/Uninstall a Program as well as other weird behaviour like losing your key store and having to re-enter your database details every time Tomcat starts up (plus other stuff I'm sure)... But finding these things are what dev servers are for... :-D

What I had to do was:

• Take snapshots of all the server VMs involved (if something goes badly wrong, just restore them and walk away whistling...).

• Stop Tomcat on all the JSS's, then on each JSS, starting with the master...

• Backup my certificate keystore (if you imported a proper cert bundle, it could be any name, depending on the name of the file you imported in C:Program FilesJSSTomcat), server.xml (in C:Program FilesJSSTomcatconf) folder as well as database.xml (in C:Program FilesJSSTomcatwebappsROOTWEB-INFxml). Because my environment had a few customisations there.

• Uninstall the JSS via the Control Panel/Uninstall a Program (leave MySQL and the Java JDK alone).

• Run the new installer using an administrator Command Prompt and the command msiexec.exe /i "path oinstaller.msi"

• Restore the files I backed up earlier (or you could just use them for reference and go through the process of manually re-entering your database details/credentials, re-uploading your keystore via the web interface and making any other custom edits to the relevant XML files that might be present for your environment (like if you've changed the max thread pool size etc).

• Run the JSS Database Utility (again you have to open an administrator Command Prompt and do java -jar "C:Program FilesJSSinJSSDatabaseUtil.jar" ) and re-configure your backup settings, Tomcat memory allocation etc if needed.

• Restart Tomcat, enter database credentials if not restoring the database.xml file, cross fingers that the database upgrades properly (it did).

• Repeat for any child JSS's.

• Profit?

N.B your mileage may vary and I'm not responsible if you break something by trying this stuff (test test test!).

Manual install would also probably work but I didn't try it. :-)

[dgreening]

I just upgraded my Windows dev server from 9.97.1482356336 to 9.97.1488392992, and I am definitely getting kicked out every time I log in, even with my local master admin account. Jamf needs to pull this installer RIGHT NOW!

Moral of the story: DO NOT EVER TEST IN PRODUCTION! Come on guys! I see this all the time: "Ran the upgrade and it borked our Jamf server! Halp!"

[tcam]

@jen.kaplan

With 9.97.1488392992
Info.plist is restricted so only onwer has read access.

ls -al /Applications/Casper Suite/*/Contents/Info.plist
-rw-------@ 1 XXX  XXXX   561 Mar  1 12:53 /Applications/Casper Suite/Casper Admin.app/Contents/Info.plist
-rw-------@ 1 XXX  XXXX   531 Mar  1 12:08 /Applications/Casper Suite/Casper Imaging.app/Contents/Info.plist
-rw-------@ 1 XXX  XXXX   528 Mar  1 12:04 /Applications/Casper Suite/Casper Remote.app/Contents/Info.plist
-rw-r--r--@ 1 XXX  XXXX  1080 Mar  1 12:55 /Applications/Casper Suite/Composer.app/Contents/Info.plist
-rw-r--r--@ 1 XXX  XXXX  1460 Mar  1 12:08 /Applications/Casper Suite/Recon.app/Contents/Info.plist

Is it safe to change this back to the standard -rw-r--r--?

sudo chmod 644 /Applications/Casper Suite/Casper Admin.app/Contents/Info.plis
sudo chmod 644 /Applications/Casper Suite/Casper Imaging.app/Contents/Info.plis
sudo chmod 644 /Applications/Casper Suite/Casper Remote.app/Contents/Info.plis

[neilmartin83]

@tcam Yep it's fine, I did this for the packaged version I deploy out to our technician's Macs.

On another note, it looks like the Windows installer got pulled...

[donmontalvo]

FWIW, we deploy the /Applications/Casper Suite/ folder set to root:wheel and 755, recursively.

[jake]

We will provide more information about the 9.97.1488392992 hotfix release to all Jamf customers today via email. If you have not received an email from Jamf by 12:00 a.m. CST March 7, please reach out to your Jamf Buddy. For those receiving the email, we request that you keep the details of this hotfix release confidential to minimize risk for other customers.

The security of your environment is our top priority, which is why we have been intentional with the timing and level of detail in our communications. That said, we very much appreciate your direct and candid feedback and we’ll continue to improve.

[donmontalvo]

@jake understood, and absolutely NDA. Thank you so much!

[PatrickD]

Thank you @jake and Jamf.

Look forward to hearing more on this as are org is now unable to implement this "important security fix" as the Windows installer is no longer available.

Pat

[daguy666]

While were at it, how bout a security bug bounty?

https://www.jamf.com/jamf-nation/feature-requests/5846/security-bug-bounty