Communication is key to making this happen and there is only so much time and so many resources. It's things like this that can make other platforms for managing Apple devices a more alluring option. I've been under pressure in the past to consider SCCM. While it might not be up to the task of matching what Jamf can do, that's not always the only variable.

I am all for holding jamf accountable and asking they build an actual disclosure process where they can communicate the necessary data to customers. However, this is no way makes me even want to touch SCCM with a 5 million foot pole.

There are other MDMs, but lets be honest here, does anyone want to use the MSFT stack to manage macOS or iOS devices?

@tlarkin I don't want to turn this into a comparison of management solutions but will say that there are reasons it didn't happen. That doesn't mean though that I won't be pressured to look at something other than Jamf.

If you are on 10.13 for one another reason, you may get a WAR file from Jamf for 10.13.1
(we are moving to Jamfcloud soon, so a Java upgrade just to get to 10.15.1 is not where I want my efforts and testing to go)

Upgrading using a WAR file, it is an "artisinal process" where you can miss putting back some of your old config files, unless you've cobbled together your own script to do this, it's best to let the already tested install scripts from Jamf do the heavy lifting. To do that we'll use the guts of the 10.13.0 .run file and put the new 10.13.1 WAR inside

#make a work folder and go into it

mkdir JamfPro10.13.1

cd JamfPro10.13.1



#download makeself and expand in work folder

curl -L https://github.com/megastep/makeself/archive/master.zip -o ./master.zip

unzip ./master.zip



#download the Jamf 10.13.0 installer for Linux, move it to your work folder

open https://www.jamf.com/jamf-nation/my/products



#expand the .run file

./jamfproinstaller.run --target ./expanded



#remove the old 10.13.0 ROOT.war

rm ./expanded/resources/ROOT.war



#download the 10.13.1 WAR from the link your jamf buddy gives you

#copy the new WAR where the one was

cp ~/Downloads/ROOT.WAR ./expanded/resources



#make a new .run file with makeself

./makeself-master/makeself.sh --gzip ./expanded/ ./jamfproinstaller-10.13.1.run "Jamf Pro Installer" ./install.sh



#for goodness sakes test it on a dev server first

I'll jump through the hoops and email security, but WHY is Jamf posting this on the forum, and not reaching out to customers via email themselves? "Criticial" security issue, and they're hoping customers stumble onto the forum and find out!?

Count me in as one who cannot move forward without formal documentation, I need to have my CTO sign off on out-of-band maintenance, and to further complicate things, I'm a contractor whose contract ends in under two weeks, before the next scheduled maintenance window. Zero wiggle room for weekend or after-hours work right now, so this means coordinating on multiple levels.... and not a hint of any outreach from Jamf's security team to their customers proactively.

This is not how you treat enterprise customers.

https://resources.jamf.com/documents/products/security-disclosure-notice-jamf-pro-10.15.1.pdf

from link above:

Now that all customers have had three days to upgrade, we are able to share additional information about the vulnerability.

This IS a communications failure.

"All customers who browsed the web forums of Jamf Nation, because we did not reach out to them to notify them".

This isn't how you deal with things at this level. Glad to have some progress, but still an utter fail in my eyes. All other companies we deal with in my office would have reached out through our account managers to notify us proactively.

Emails were sent out over the weekend. If you didn't receive it you may need to check your spam filtering or check with jamf support on why you may not have received it.

There was an email to cloud users were they got an update schedule.

Then there was an email to customers with the subject line "Critical Security Upgrade: Jamf Pro 10.15.1" from notifications@jamf.com
containing an acknowledgment of a vulnerability then a link to "more info" in the release notes. as well as a request to reach out to Success@jamf.com with any question we may have.

this forum post was by far the most info available at first but still not enough. Security@jamf.com filled in the many blanks so that I can get changes approved. and the announcement today seems to be closer to what we all wanted originally

Just took a few minutes to read through this thread. Great read and good discussion. I think if Jamf had added this line to their initial communication from 9/28, this would have satisfied most customers who have to deal with change control:

"To protect our customers while preparations to upgrade are made, Jamf will not be immediately releasing public details of this vulnerability. If you require more technical details of this vulnerability for beginning the remediation and change control process at your organization, please contact security@jamf.com."

Google did something similar with Chrome a week or two ago when 77.0.3865.90 was released to patch a huge security vulnerability.

As others have posted, some organizations have more rigid change control policies and procedures than others. Thankfully I do not, but I can see why the initial obfuscation of communication would make some customers angry.

That being said, I can understand how Jamf wanted to hold some data back so that malicious actors didn't start port scanning public IP ranges looking for hosts affected by this vulnerability, and then having hosts ending up in Shodan (or something worse) before admins had time to patch. Hopefully Jamf is listening for the next time this occurs.*

*Hopefully there won't be a next time.

Has the CVE number been posted yet?
I can't override my companies Change Freeze window without it.

I still take issue with one line in the official disclosure.

"This issue only impacts the Jamf Pro server and does not impact managed clients or client management functions."

This is 100% false and Jamf should stop propagating this. According to the disclosure, exploitation of the vulnerability could result in remote code execution as the Tomcat user on the server. If an attacker can get RCE with all the rights of the user running Tomcat, this means the attacker could read the plaintext database credentials from the DataBase.xml file. With those credentials, an attacker could:

• Delete, modify, or add new scripts to the database, which run as root on the client


• Send MDM commands to enrolled devices


• Delete, modify, or add new packages


• And any other action possible with full access to the database, which is anything

An attacker could reach out and impact all managed clients and client management functions.

Emails were sent out over the weekend. If you didn't receive it you may need to check your spam filtering or check with jamf support on why you may not have received it.

Thank you for that. For what it is worth, Jamf did reach out this afternoon after seeing the post. They apparently sent an email, but to a contact I've never heard of. Now going through the list of contacts they have for us and cleaning it up - somehow have 9 names on the list, and mine is the last one. So I can say that at least they made an attempt, but looks like the person contacted may be someone in a procurement office. (we have 20,000+ employees, purchasing doesn't even happen in the same State where I sit).

Has anyone elses pre-stage scope gone "blank" ?

I did get an email about an hour ago notifying me of the update, but it makes reference to "last weekend, we alerted you to a critical vulnerability..." which did not seem to occur.

I also received a call from Jamf, following up on the apparently-missing email. They seem motivated to get to the bottom of why I didn't receive the notice, but have received similar (non-security) update emails, which is appreciated.

We did not receive (and still have not received) any emails from JAMF about this.

If not for seeing the Register article this evening, we still wouldn't have heard about it...

I also don't see any guidance on determining if the issue has been exploited, and any recommended remediation if it has been.

@iviemeister

The TL;DR is that the vulnerability is bad enough you'll want to update as soon as you can. The rest of the ramblings in this thread is about proper disclosure process, and that is the gist of it.

@tlarkin

Yeah, we updated ASAP after seeing the article, THEN came here to find out why we were not notified.

Guidelines for detecting prior exploitation would be good to have...

Now that we have it patched, I second everyone on here's posts about how communication was not done right.

Had we been taken into confidence Monday when I first called asking questions, I could have put in an emergency change control request Monday night and had this patched already. I didn't know what was going on until AFTER our pre-scheduled change control meeting on Tuesday (early in the day). Since I had no clue what the flaw was at that point despite escalating to support twice, I had to push change control through on iOS compatibility grounds and "a flaw that Jamf considers bad". As such our change control folks and I scheduled the change for tonite on a Wednesday (our night for changes generally.) Later Tuesday when I saw how bad the problem was, I wanted to get it patched Tuesday night, but my family already had other commitments by that point.

Basically Jamf's fail on not getting legit folks informed in a timely manner cost me 48 hours of time in which I could have had our cluster patched had I known the severity of the vulnerability.

When do you expect to roll out automatic Jamf Pro upgrades? It's a pain in the butt constantly having to visit the website, download the new version, replace it, and get up and running. It would be wonderful if we could tick off a check-box for automatic upgrades, or have it sync to upgrade to the latest version of whatever Jamf Pro Server is on.

Also, the download to 10.16 is broken, so I'm stuck unable to manage packages for the time being: https://www.jamf.com/jamf-nation/my/products

Automatic updating of an on-prem production server is the last thing I would ever want, FWIW.

For cloud, I get it, the main reason we run on-prem is to keep tighter control.

As for the download - give it a min and try again? I just downloaded both the Mac and the Windows installer without a problem, so may still be propagating on the CDN.

[edit. Realized I completely mis-understood you. You're talking admin packages, not auto upgrading the server. My mistake and apologies]

@tlarkin Kudos! One of the responsibilities we have, as subject matter experts (SMEs) for the macOS platform and management tools, is to mentor our IT groups.

The more effective we are at mentoring, the more trust trust and confidence we gain, and the more success the platform will have in the environment.

(Apologies if the word "mentoring" triggers some folks...hey, its the 2020s...but can't think of a better word to describe this.)

Also, to accept any risk, one must understand what that risk is. If you cannot understand the risk, you just have to assume the worst. Which is not a great way to do business.