Summary of macOS 10.13.4 information and links

Awesome post!

I tried Jeremy Baker's script. It doesn't work on an unmodified Mac until you grant Accessibility to Script Editor. Also, you can't do this part programmatically because Accessibility Settings are now protected by SIP (/Library/Application Support/com.apple.TCC/TCC.db). It is sqlite3 formatted, so you could read from it. (sqlite3 {filename} 'select * from access;')

In other words, for JerBecause's exploit to work, a remote technician would have to 1) enable accessibility services for Script Editor, 2) paste in the script, then 3) run it, and 4) remove the entitlement from Accessibility when finished.

Nevertheless, I can envision a scenario where an office worker answers a call from someone pretending to be from tech support (do you know all your IT guys by name?), who tells them that their computer is not showing up in some report, and needs them to run a fix remotely to correct the issue. They start a Bomgar or LogMeIn session, five minutes goes by, and voila, system compromised with malicious MDM profile. That is why Apple created UAMDM, and now thanks to JerBecause's script, Apple will likely patch this workaround as well. The fastest way to kill it is by removing the Accessibility hooks within the Profiles pane only. If you're physically handicapped to the point that you can't use a mouse, but need MDM, let's face it—someone is going to have to help you with this part.

Fun fact: if you press Opt-Shift-K, instead of pasting the "apple" logo, it gets replaced with the command symbol . The embedded Proxima Nova font has the "Command" symbol mapped to Unicode U+F8FF, which is the "Private Use Area" that normally contains the Apple logo. You can see this for yourself by loading Font Book > 2 (Repertoire) > scrolling to the bottom. Many fonts include the Apple logo in their repertoire. Additional reading: FileFormat.info, Wikipedia, SuperUser, Harvard

Cool, great post! any installers already available?

@txhaflaire : Yes. Jamf Pro 10.3 was posted yesterday, and macOS 10.13.4 was released today as well.

The standalone package hasn't hit the main Apple downloads site (you can search for packages named 'High Sierra', though!), but it is available in the Mac App Store right now.

@bradtchapman

Cool, Thanks! need the .pkg installers for deployment via Self Service, something with bandwith struggles and couple of hundred devices.

@txhaflaire No direct download links yet, but if you want to poke around, there is always SUS Inspector

Thanks, @RobertHammen.

@RobertHammen I've got bookmarks, snippets, clippings, screenshots and illegible written notes on all of that littered all over the place. Thanks for organizing it!

32-bit app warning - profile to suppress? Do tell, what's the syntax?

Thanks for the post @RobertHammen Very informative.
One question I'm trying to find an answer on. Do the new SecurityUpdate2018-002 patches for El Cap and Sierra require that the previous SecurityUpdate2018-001 patches have been applied first on those respective OSes, or does this new one supersede that update? It may not be that important, but I still have some machines pending check-in in our fleet to run the previous patches, and I'm wondering if I should replace the update being pushed with this new version and it will just work, or if it will fail because the previous update wasn't applied.

I'll probably set up a test machine to run this on to see, but was just wondering if anyone knew or figured this out already.

@mm2270 Security Updates are typically cumulative - meaning it's OK to skip -001 as long as you get -002. I haven't actually compared the package sizes, but usually the updates get larger as the year goes on...

@dpertschi Of course, the prolific @rtrouton has a profile to disable the 32-bit application warning in his GitHub repo

Error looks something like this:

I'm testing this on some lab machines that are AD bound. I got the attached pop up on one account, but only on one account. I'm using a mix of previously signed in and new to this machine accounts. I see above that this issue is known, but since it's intermittent I can't figure out how much of an impact it will have for us. Anyone have more information on what triggers this?

@McAwesome This came up during Beta testing, search developer.apple.com for lots of heat on this. Apparently the fix didn't get added, where LDAP users would automagically get their SecurityToken? FWIW can you confirm you're on the public release though?

@donmontalvo Confirmed, from official released 10.13.3 updated through the App Store to 10.13.4.

This is indeed the "poor user experience" referred to in my original post. Please open an AppleCare Enterprise case, or file a radar on this, if you find this behavior to be problematic. To me, it's the replacement for the old "Keychain password" dialog that confounds users.

@RobertHammen I've contacted our org's Apple rep and he's forwarding the issue.

There they are!

Download macOS High Sierra 10.13.4 Update -> https://support.apple.com/kb/DL1962?viewlocale=en_AU&locale=en_AU
Download macOS High Sierra 10.13.4 Combo Update -> https://support.apple.com/kb/DL1959?viewlocale=en_AU&locale=en_AU

10.13.4 Combo Update
10.13.4 Update (from 10.13.3)
Security Update 2018-002 (Sierra)
Security Update 2018-002 (El Capitan)

• Mac on 10.13.3 has one MDM profile, should have 5 from Jamf
• user upgrades to 10.13.4, still only the one MDM profile
• No apparent way to fix this problem, because we can't delete the ConfigurationProfiles folder, profiles won't push down from Jamf, and there's no other way to force it.

Wat do?

@znilsson do any of these help?

sudo jamf reenroll
sudo jamf removeMdmProfile
sudo jamf mdm

If the MDM profile is there fine but you're just not getting config profiles, see what the inventory record says under History/Management. See whats scoped and why it failing

@znilsson I've seen on some test machines that the MDM profile has to be manually accepted before it'll start working again even on machines that, according to Apple, shouldn't need any action taken. Have you approved those?

You had me at --eraseinstall

@aaronpolley Unfortunately my user has been off network for a couple days so unable to test. I reenrolled manually using a QuickAdd, didn't fix it. I ran sudo jamf mdm, that didn't do anything. My next attempt will definitely be to try removeMdmProfile, I have to wait until he's back on network first is all.

Unfortunately the inventory record doesn't help. I can see all my profiles are scoped, and the inventory just says they aren't there. No explanation, they just aren't there. One clue is that the record in jamf says MDM capability: No, meaning Jamf doesn't think this Mac is MDM capable, despite the Mac having the Jamf MDM profile on it. And @McAwesome, I checked, there is no option to allow it from the user side, it's already valid and doesn't require any further approval.

It's a pretty crap situation.

@znilsson

If you have SSH on:

First:

sudo jamf removeFramework

Next: Re-Enroll w/ QuickAdd or Recon.app remote enrollment

That should do the trick.

EDIT: Great OP @RobertHammen

Just wanted to add that after a quick add you need to approve the profile in system preferences.

1: Choose Apple menu > System Preferences, then click Profiles.
2: Select your enrollment profile that has a badge: .
3: Click the Approve button on the right, then follow the onscreen instructions.

But the SecureToken prompt still comes up when new users enroll. When bypassed the login time is extremely long on my test mac.