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.

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.

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

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

Also ironically, my comments are now moderated.

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.

@bvrooman wrote:

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

+1

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.

Still haven't received an email either.

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

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

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

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.

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

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

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

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

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.

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.

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.

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

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. :-)

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!"

@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

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

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