Is this currently being exploited to your knowledge? Do you have a CVSS score for this vulnerability?

Thank you for your question. I am Jamf’s Chief Information Security Officer and will be answering questions where possible.
Because this is an ongoing security issue, we are not able to share much detail at this time but we will make every effort to provide as much information as possible. The security of your environment is our top priority which is why we are being intentional about how we communicate about this issue.

We are not currently aware of any attempts to actively exploit the vulnerability. We consider the issue serious, and recommend all customers patch. More information about the specific issue will be communicated directly to customers as soon as reasonable.

If you are upgrading from a version older than 10.14.x, please check this article for Incremental upgrade instructions:
https://www.jamf.com/jamf-nation/articles/647/incremental-upgrade-scenarios-for-jamf-pro-10-0-0-or-later

Hi @Aaron.Kiemele, I'd ask you to consider this feature request:

Email Options: JAMF Security alerts and vulnerabilities

Thanks!

Is there a CVE and severity rating for this issue? The reason I’m asking is that having a CVE and severity rating will help with emergency change requests in certain organizations. Otherwise, upgrades at those organizations may have to go through the normal (and potentially much more lengthy) change request process.

We understand that there may be a desire for more information and intend to share additional details as we’re able. In order to best protect all customers, we are intentionally limiting public information at this time as upgrades continue.

We continue to recommend all customers upgrade to Jamf Pro 10.15.1 immediately to mitigate this issue.

Will there be a 10.14.x release? We have a Jamf Pro instance which is still running 10.14.1 because iOS 9.x was removed from minimum required compatibility with 10.15.0.

I have to agree with Rich Trouten here. You don’t want to give out any information. You need to find a way to then list it as a critical update if that is the issue. If I can’t get a CVE I can at least use that to get an emergency window to update. Without it I have no recourse and will be required to use the next maintenance window which right now is a couple of weeks away. All I need is a severity rating with an official document or a URL. A Jamf Nation article isn’t going to cut it.

@Aaron.Kiemele

Can jamf at least disclose this type of vuln? Is it a RCE, DoS, etc? Many times when going through changes, especially during an end of quarter change freeze, Orgs might need to know more info to weigh the risks.

Thanks
Tom

Seconding what @hunter990 and others have said. We need a CVE number and a description of the vulnerability to escalate an emergency change control.

I had been planning to upgrade to 10.15 next week, but if I can do it sooner then that would be super.

As we have seen our user facing server server misbehave very badly just before I got the email about the update I really would like to know a bit more about the vulnerability and its potential impact. When I read "potential to impact the integrity and availability of your web server" I want to know in how far the integrity of the server may be impacted, and what are the signs of an impact I may have to look for.

To me "impact the integrity" means someone can gain privileged access to the server, install back-doors, extract and even change information. For servers that configure plenty of clients this is a nightmare.

So I would appreciate more assurance that it is not required to re-install the servers and to restore a backup of the database matching a date before my server started to act up massively.

What I forgot to say: I appreciate a lot the fact that Jamf made a fixed 10.13.1 version available. I spent the day preparing and testing the upgrade from 10.13 to 10.15.1, and the change of the java version required a lot of fiddling with the config management.Would I have had to change the MySQL version as well I would have been stuck...

@Aaron.Kiemele if Jamf wants to be a “big boy” software company, they need to abide by the same rules and standards as others. Organizations need a CVE to justify and coordinate an emergency maintenance window to patch this vulnerability. You’re not helping your customers by not empowering them with this information.

Echoing @rtrouton, we are also in need of a CVE to get this pushed through our quarter-end change moratorium. I understand the need to keep the “how” under wraps, but I also need more than a “because Jamf says so.”

We are intentionally limiting how much we disclose about this issue on this public forum. Any Jamf Pro customers that require additional information to properly handle an unplanned upgrade should contact their account team, or Security@Jamf.com. We will do our best to provide more granular data one-on-one.

The CVE ID has been requested and is being processed. We will send an update as soon as we receive it.

Can we safely assume this is Remote Code Execution on the Jamf server e.g. via a mechanism such deserialisation? If the bug can impact the integrity and availability of the Jamf web server, what stops the exploit taking control of the Jamf fleet?

Forgive my ignorance here, but would it not be possible to disclose the potential impact/outcome of this exploit without disclosing the how? Surely that would be enough data for most organizations to determine how severe the impact is to them?

Withholding information from your customers is not a way to earn trust. Transparency and honesty is the only way to handle situations like this. We deserve to know what is going on and what our potential impact is.

This does not look good.

I need to understand if I'm at risk for this or if I can wait to upgrade my entire environment to a version of software that came out hours ago.

I think it's pretty obvious that this is pretty serious and that everyone can be affected. Jamf has their reasons for withholding and it certainly benefits us from a security standpoint but I do agree it would be nice to know at least something about it(severity rating, etc.). While I as a tech person might understand this situation, it doesn't always mean the people I report to will see this with the same urgency as there are processes in place to deal with different situations. Jamf needs to realize that many of their customers are in situations beyond their control where they don't have someone sitting in front of a computer and reacting on the fly to patch immediately. The world has become full of business processes.

@Aaron.Kiemele

I reached out to our account rep per your instructions, and I was referred back to this thread.

Any Jamf Pro customers that require additional information to properly handle an unplanned upgrade should contact their account team, or Security@Jamf.com. We will do our best to provide more granular data one-on-one.

So at this point I can only assume that the issue is a recursion loop.

We are working to be transparent in a responsible way, by limiting public disclosure for a window of time to provide opportunity for organizations to go through the change process.

Any Jamf Pro customers that require additional information to properly handle an unplanned upgrade should contact their account team or Security@Jamf.com. We will do our best to provide more granular data one-on-one.

@kitzy Please email Security@Jamf.com and we will respond quickly with additional details. Apologies for the miscommunication.

This, unfortunately, seems to happen virtually any time Jamf announces anything security-related. It's not an appropriate response from a mature enterprise software developer.

I get an email from Apple on the same day they release security patches listing the specific CVE and a summary (for example, "A remote attacker may be able to cause unexpected application termination or arbitrary code execution"). From that, I can pull up a severity rating and know if this is a "patch it next week once everyone has been notified and approves" or a "put in an emergency change and have some downtime today" situation. There's nothing in there telling me how to exploit it, and security is not (further) compromised by the disclosure.

If Jamf Pro's vulnerability is something so egregious that it can be exploited trivially, then put the actual disclosure in My Assets or similar. The key, as numerous others have mentioned, is that information about the vulnerability — complete enough to be reviewed and acted upon by security and application teams — needs to be made available. A vague statement of "you should patch because this one's pretty bad you guys" is not acceptable, especially if that's what is being delivered to people who have already escalated to their account team.

+1 on everything @bvrooman said.

I echo @bvrooman post. The example they provided is exactly what I expect and receive from other software vendor like Microsoft, Adobe, Google, etc...

The decision point for my organization right now with the information provided is do we treat this as if its the worst case scenario and assume its a vulnerability that could lead to unauthenticated remote command execution or do we hope its a denial of service vulnerability and wait for more information to come from JAMF before determining how and when we update.

Echoing others concerns here. We have the 10.13 -> 10.15 upgrade in the pipeline, and really need to know the severity of this so that we can either patch to 10.13.1 in the immediate timeframe or wait for the scheduled 10.15.1 upgrade. Enterprise Change Management requires the CVE details which have been requested again and again.