Zombieloadattack and force updating MacOS – part 2

Patching your MacOS to the latest version is only a partition solution, it prevents JavaScript exploits via safari. It does not resolve the issues for other browsers for now. When researching I ran into this article that explains a bit more on how this works:


Store-to-Leak Forwarding

Store-to-leak forwarding also reads pre-loaded data by exploiting the efficient way in which computer processors function. “The computer assumes that I want to use the data which I have just written to the processor again right away. So it keeps it in the buffer for faster access,” explains Gruss. This functionality can also be used to determine the architecture of the computer processor and find the exact location where the operating system is running. “If I know exactly where the processor is running the operating system, then I can launch targeted attacks against flaws in the operating system.”

More Information: https://cpu.fail/store-to-leak.pdf


So to fully mitigate this attack is to disable the hyperthreading for now. This can be done from the recovery mode.

  • Restart your Mac and hold Command key and the R key to enter macOS Recovery mode.
  • Open the Terminal from the Utilities menu.

    nvram boot-args=”cwae=2″

  • Run

    nvram SMTDisable=%01

  • Restart the Mac.


Make sure to read this post with much more detail on why and how to do this:



So if you “disable half the threads” in a Mac processor you lose half the power. This got me thinking… do I really want to do this for all of my machines. Also this cannot be scripted afaik.

Chrome and Firefox will be releasing updates soon (they better!) and should help.

Will you be disabling hyperthreading on your fleet?



I did get some useful feedback from people regarding forcing users to update:

Nudge – thanks to justunholt

A tool to help users with pre-existing devices upgrade their OS version.


A-Kinder-macOS-Update – thanks to Taboc741

A workflow for more user intuitive macOS updates. Allowing the user to defer updates to a more convenient time after updates become available, while allowing for greater assurance that security updates are being applied to IT.





Zombieloadattack and force updating MacOS

10.14.5 was released today. At the same time news of a brand new vulnerability that can get low-level access to your Macs memory. Well not all Macs, but if it was built in the last 10 year basically.  But wait there is more! The awesome thing about it is that it’s can be done when you are visiting a website.

Here is some more info about it -> https://zombieloadattack.com

This means I need to deal with this update quickly. We had the policy to delay updates so we will need to rethink it.


Here is the plan of action for tomorrow:


First I would really like to thank my previous self and our team for setting up Jamf last year so we don’t need to run around now.


1. Smart group – Macs not upgraded to 10.14.5.

2. Policy – Create an APFS snapshot for rollback, just in case. Trigger next policy

3. Policy – cache the MacOS installer on the client machine.

4. Smart group – Macs that have the finished caching the latest update package. Assign to the next policy.

5. Policy – give a popup every 4 hours to the users to save their work, close all apps and run the update. Let them know why we are doing this and that it might take 30 min.


I do have a few questions for you guys:

How are you dealing with urgent updates?

Where do you get your security news?


UDPATE – Created a follow up article:



macOS security – Secure Kernel Extension Loading (SKEL)

Some background first

As we get ready to approve kernel extension for our Apple fleet, here is some background on how things evolved.

Kernel extension (KEXT) – MacOS kernel combines the features of a microkernel (load the minimum to run the OS separately from other services) and a monolithic kernel (everything needed for the OS, drivers and filesystem are in the kernel space like BSD). In MacOS, kernel extensions are used by different applications to grant low level access to the hardware. For example, some software, like Antivirus, require access to the computer hard disk and memory to function correctly.

Depending on the skill level of the developers writing these apps, some kernel extensions might be poorly written. There are some apps that don’t even remove the kernel extension when you uninstall them. Others can cause random crashes to your OS or slow down your machine. Apple wants to give the user control over the applications that are installing kernel extension on our Macs and gives the MacAdmins a way to approve them for your fleet.


Let’s take a look how the security of Mac OS evolved over time.

OS X 10.8 (Mountain Lion, and earlier, 2012) – Digitally signed kexts are not allowed and wont load.

OS X 10.9 (Mavericks, 2013) – Signed kexts will load but not enforced.

OS X 10.10 (Yosemite, 2014) – Signed kexts enforcement. Your kext will not be loaded if it’s not digitally signed.

OS X 10.11 (El Capitan, 2015) – SIP is now taking care of the code signing verification.

OS X 10.13 (High Sierra, 2017) – Secure Kernel Extension Loading (SKEL) is managed now by System Integrity Protection (SIP).

User Approved Kernel Extension Loading (UAKEL) was introduced to give users control over which kernel extension are allowed to load on their Mac during the software installation.

User Approved MDM (UAMDM) – As an admin, you want to manage certain security-sensitive settings on a Mac to keep security tight. If you use DEP, you are good to go since the device already belongs to your account. The other option is to manually “Approve” additional management privileges from the users computer.

The idea behind this is that some actions have to be approved by the user of the Mac so that a sneaky MacAdmin won’t be able to run items on a user’s personal device without their knowledge. Any user, not only computer administrators, can approve a kernel extension unless restricted by the MDM.

You don’t have to enroll to an MDM to approve kernel extensions manually and can approve them when notified during installation, via the security menu in system preferences.

A few important notes

  • When you are upgrading to macOS High Sierra or later, all third-party KEXTs that were already installed at the time of upgrading are automatically approved and don’t require any user action.
  • Automation or attempting to enroll a device remotely via screen sharing will not result in a “User Approved enrollment”. You have to connect a mouse to the device and click a physical button. You can connect via Apple Remote Desktop app and use a USB mouse to click a button if there is no screen connected to the device.
  • When approving KEXTs manually and if not approved during installation, the approval “Allow” button is only available for 30 minutes after booting, will reappear after a restart in the “security and privacy” -> “general” tab. However, you will no longer see that pop-ups asking you to approve the kernel extension

Back to kernel extensions, once a device is “User Approved” you can use the MDM to whitelist the kernel extension you approve in your organization. More on that below.

Let’s get technical

To identify the KEXT, macOS uses Team Identifier to identify the vendor or Bundle Identifier to identify the specific application installing the KEXT. Here is a community maintained list of known identifiers :


If you want to whitelist the vendor like “Google” you can use their Team ID “EQHXZ8M8AV”. This means that any future KEXTs by Google are automatically approved. If you prefer to whitelist Google File Stream you can use the Bundle ID “com.google.dfsfuse.filesystems.dfsfuse”. However, you must specify the Team ID in both cases

Location of Kernel Extension

Approved and system KEXTs can be found in:


Newly installed 3rd party KEXT are copied to the folder mentioned below and once approved, a copy of the extension is made to the one of the folders above and allowed to load.


Working with KEXTs on your mac via CLI

/usr/libexec/PlistBuddy -c print /Library/Extensions/Dropbox.kext/Contents/Info.plist
  • List approved kernel extensions on the Mac
kextstat | grep -v com.apple
  • Find the location of the kernel extension
kextfind -bundle-id com.getdropbox.dropbox.kext

kextfind -b com.getdropbox.dropbox.kext
  • Unload until next reboot
sudo kextunload /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext
  • Load until next reboot
sudo kextload /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext
  • Remove kernel extensions (should back up just in case)
sudo rm -r /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext
  • Get the Team-ID and Bundle-ID of kernel extensions on your Mac
sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT team_id,bundle_id,allowed,developer_name,flags from kext_policy"
  • Get the list of MDM approved kernel extensions
sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT team_id,bundle_id,allowed,payload_uuid from kext_policy_mdm"
  • Get the audit history of kernel approvals on your Mac
sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT path,team_id,bundle_id,boot_uuid,created_at,last_seen,flags from kext_load_history_v3"

! Any modifications to the Kernel Extension User Consent must be done from the Recovery OS only !

  • Add the Team Identifier into the list allowed to load kernel extensions without user consent (from Recovery OS)
sudo spctl add <team-id>        
  • Remove the Team Identifier (from Recovery OS)
sudo spctl kext-consent remove <team-id>   

The wrong way to deal with it

If you want to remove this security feature from your environment and are ok with the risk, you can turn off the Kernel Extension User Consent from the Recovery OS. Not recommended.

  • Boot to recovery and check status of KEXT approval (bad idea)
sudo spctl kext-consent status
  • Boot to recovery and turn off KEXT approval (bad idea)
sudo spctl kext-consent disable
  • Boot to recovery and turn on KEXT approval (bad idea)
sudo spctl kext-consent enable

Resetting NVRAM will reset those changes. You can set a firmware password to prevent unauthorized changes.

The easy life with an MDM (JAMF in this case)

As mentioned you must enroll the computer via DEP or “Approve” the newly enrolled device manually. The best way is to use the user enrollment web page by going to:


Add  a separate JAMF account for each member on the team that can only perform enrollments. This way you’ll have an audit trail of enrollments to your MDM and it simplifies monitoring.  

This will install a certificate (if its self-signed) and an MDM config profile. Once this is done, you can push the config profile with the approved KEXT Team or Bundle ID payload to the device.

The approved kernel extension payload must be pushed via an APNS transaction from the MDM server to a Mac. A profile with this payload will not work if it is installed via script and/or package.

Use a separate Config profile and apply it to the Mac before deploying the software that installs the KEXT. You can to deploy all of the kernel extension to all company computers.

Give the profile a general name like “Approved Third-Party System Extensions” to avoid questions from users.

Finally the JAMF payload itself

Now let’s create and deploy the KEXT approval payload with the MDM. Create a new configuration profile and define the desired scope. Add the Approved Kernel Extension payload with the relevant details. Here is that community google sheet link again:


Save and ….. Done.


APFS- Apple file system

As I was reading the book “macOS Installation” by Armin Briegel, I realized I need to learn more about APFS, here is a summary of what I found.

Why APFS is here

  • HFS is 30 years old, was designed when there were no permission, no hard links, no extended attributes and checksum in mind. Apple added and corrected many times over the years which cause the system to become less efficient and …. kinda crashy. The biggest issue with that is that files on HFS could get corrupted over time and you would lose your precious photos after all those years.
  • Apple needed a file system for its newer devices like Apple watch and AppleTV
  • The increasing use of SSD technology. APFS is optimized for flash and solid-state drives and leverages their high seek and access speeds, much faster than spinning drives.
  • Improving the encryption and making it hog less CPU.

The benefits of APFS

  • Optimise the space of the HDD used and increase free space by using clones for file copying and using deltas.
  • Improve the write speed by removing the need for journaling and switch to “write on copy” and by changing the way file are stored and pointed to on the disk. This is efficient on SSD. When you make a copy of a file no blocks are copied and a pointer is added from the new file to the previous file’s data. If you make changes to the original file, APFS created new records in the file system with the changes that you made. This is possible due to the low access time of SSD vs HDD that take time to spin the drive.
  • 64-bit file system that helps with space savings and performance improvements
  • Snapshots – they are allowed by the “write on copy” that enables you to “copy” a huge chunk of data within seconds
  • End users can store up to nine quintillion files on a single volume, boom! (only 4 billion today))
  • Natively support encryption vs Filevault 2 which was part of the OS and not the filesystem. This allows encrypting parts of the files for different purposes or users.
    You can create a separate encrypted partition for your personal files.
    Also possible to encrypt specific files or metadata.
  • Apple also changed the way to decrypt the APFS partition. The Preboot volume has the data needed to boot to the FileVault preboot login screen and to decrypt the volume (Using the T2 chip to verify integrity, more on that in future posts)

APFS container

  • With APFS an abstraction level called “containers” was added. Volumes now reside in containers and those volumes can “share the free space” meaning they can change without repartitioning. Yey!

The downside of APFS

  • Not compatible with HFS+ or NTFS . MacOS 10.12 and before will not be able to access it.
  • Should not be used on HDDs due to “write on copy” and the “fragmentation” of copied files. HDDs have low seak speed and will be slowed down by this feature
  • Does not support direct hard link, will be converted to soft links during the conversion (During an upgrade to a new OS)

What can we do with it

  • Take a snapshot of your Mac APFS container during testing and revert to its original state instead of reinstalling. Read this article by the awesome Emily to get some info.

Here are some of the commands:

tmutil     - make snapshots on apfs command (old time machine control)

Ctrl+Option+Command+T    - Open terminal during Setup Assistant and Mac installation.

tmutil snapshot - take the snapshot

tmutil listlocalsnapshots / - list the snapshots

tmutil deletelocalsnapshots 2018-12-12-083439 - delete specified snapshot

tmutil thinlocalsnapshots / 1000000000 1 - remove older snapshots based on priority
  • Take a snapshot before a major upgrade or add this to you scripts or Jamf self service before upgrading the OS.
  • Snapshots are kept locally for up to 24 hours and also erased based upon free disk space. You could create a script or use launchctl (or crontab) to take a snapshot every X amount of time without having the Time Machine drive connected for local

Resources used:

Changing wallpaper on new users computer

I’m learning to love Jamf every day and this time it’s the simple task of setting the wallpaper for newly installed computers


There is a simple way to setup a Wallpaper with a configuration profile. However, this will force the wallpaper and people will not be able to replace it later. I did not want that functionality.

I found a nice method that I’ll describe here that ended up working for me. One thing to note is that I do not have DEP and the policy runs from the users account that I manually create on the Mac.

The first part is straightforward. I packaged the wallpaper PNG file to be deployed to the users’ document folder with the Jamf composer. I used FEU (Fill existing user home directories) to make sure it goes to the users home folder and does not create one with my username in the path. Then I exported to a dmg file as .pkg files will not work with FEU.

Next, I used this amazing tool called Desktopper on Github. Packaged it and deploy the .pkg in the same policy. With Desktopper you can point it at the PNG file I copied to the users’ Documents folder and set it on the some or all displays as the wallpaper.

I could use the “Files and Processes” section of the policy but then the desktoppr will run as the root user and will not give me the result I want.

The solution I ended up using is called Outset and can be found on Github and…. it is awesome. Outset is a script which automatically processes packages, profiles, and scripts during the boot sequence, user logins, or on demand.

What I need to do is put create a script with the correct permissions, that will run the desktoppr and set the PNG file. That script went to the “login-once” folder of Outset. This way the script will apply the wallpaper after the first login for every user on this Mac. Added it to the scripts in Jamf. This was the last piece of the puzzle.

## Create a script in the outset Run-Once folder
cat <<EOF>> /usr/local/outset/login-once/SetWallpaper.sh
/usr/local/bin/desktoppr main ~/Documents/FBwallpaper.png

## Give the script execute permission
chmod +x /usr/local/outset/login-once/SetWallpaper.sh

As scope, I set up a new smart group that includes all of our user machines that were enrolled in the last day. I do not want this to replace the wallpaper of my CEOs favorite cat or something. So that’s it, guys. Please let me know if you have a better way to get the job done or any questions.

Working with Plist files

In this article we will go over .plist files, defaults command and some software to work with plist files.

Background info

All of the Macs preferences are stored in plist files (property list file). Some settings are not accessible from the GUI of the MacOS or its applications preferences menus. You might also want to configure an application before a user launched it on a new Mac he just got : For example, you might want to set the default home page for a browser, adjust the screen to lock after three and a half minutes or set the VPN configuration.

Every time you make a change to a setting via any menu, those changes are reflected in the relevant plist file by updating an entry and setting a value on that entry in the relevant plist file. It looks like an XML file, but if you try to open it, you will not be able to read it with a text editor as it is a binary file. You need a program to interact with those files. This is where the defaults command comes in.

We can take a look at the many .plist files located at:



Preview plist files

MacOS has a nice feature that allows preview to display the content of a plist file that is readable. Once you select the file you want to view, hit space, and the content will be displayed.

Quick edit plist files

When you are using the defaults command you need to specify if you want to read a plist or update it.

defaults read com.apple.finder

View only the value of AppleShowAllFiles. The result can be TRUE, FALSE, YES or NO.

defaults read com.apple.finder.plist AppleShowAllFiles

Let’s change the value so that we can see all files and verify it was changed.

defaults write com.apple.finder.plist AppleShowAllFiles YES

Converting plist files to text

You might need to convert the plist file into something more human readable. Use the plutil command to convert plist to txt. I use this when I need to take the content of a plist file and paste its content to JAMF to deploy it. Make a copy of the file you will be converting and…

plutil -convert xml1 com.apple.finder.plist

You can reverse the conversion using:

plutil -convert binary1 com.my.app.plist

Applying what we learned + some useful apps.

You would like to change the homepage for all your Macs in the Chrome browser to your company portal.

  • The first thing to decide on is this a user or a computer policy and how will you be deploying it
  • Now you need to know where is the file that you need to edit. This can be done by Googling the file to update and then using the defaults command.
  • You can also look at the file system changes when you are making that change on a virtual MacOS. I love an app called http://fsmonitor.com/. It gives you this nice tree look of the live updates to the OS.

  • Another super great tool is Pref Setter. It will show you a list of all the plist found on the Mac and gives you an option to update from inside the app. I would not recommend using it to update, it’s quite old, but it is great to get a general view.

  • PlistEdit Pro is my tool of choice for editing. It gives a great visualization and simplifies editing. There is also a more affordable alternative here.

  • There is also a tool that is provided by Apple called plistbuddy.. I have not used it yet but heard it mentioned several times on the MacAdmins podcast.

Adding default settings to packages

Let’s say that that you are building a package with JAMF composer and you need to add some default setting for that app. Once you add the app and use a post-install script to run the defaults command with the values you want. Make sure to build a .pkg file though if you want it to work correctly.

Well, that’s it for now guys. While doing some research for this article, I found a book by Armin Briegel (https://scriptingosx.com) . His book Property Lists, Preferences and Profiles for Apple Administrators is only available with a US Apple ID. Perhaps future books will be as he mentioned on his blog post.

Fully loaded Mac – in the past

We covered the features Apple is giving us to manage our macs in the previous post. However, some of those features are not yet available in Israel. They will show up here eventually, possible with Apple Business Manager release in the next few months.

In the meantime let discuss how we used to deploy new Mac, what worked for us so that later we can talk about the direction we are moving in. Let me know in the comments if you have any suggestions or questions.

Administrative tips

First, we purchase our Macs through a big company that will have significant interest to be approved to be a DEP reseller once it is available in Israel. This way we will probably be able to ensure that previously purchased equipment will be added to our account.

Once the Macs arrive, I do not open them right away since Apple’s one year warranty starts at the moment you activate them (connect to the internet for the first time). I do have a few spare Macs ready to be given just in case someone forgot to let me know about a new person that has already started working … yesterday.

I consider it best practice to have the same configuration across all the fleet per job role and the same color of devices for all. All RND folks get the same machine, and all support get the same weaker configuration. It is simpler to manage, troubleshoot and does not cause people to complain about their hardware.

As soon as I find out a new person is starting, I will fire up that Mac and ….

Deployment workflow

Here is what I used to do so far, later I’ll go into what we do now. So the first thing I did was go into netboot mode on the Mac and put a primary image on the laptop. Even if there was a working version of MacOS, I would erase it. Never know who touched the Macs while in transit and also want to have a consistent setup for all of our devices.

We used Deploystudio and had an image for every computer type. This does add the task of keeping the images up to date, but it is relatively simple as you create a new image after a new deployment and an upgrade of the OS and drop it back on the deployment server. The more diversified your Mac fleet is, the more images you will need to maintain.

Part of the Deploystudio workflow is to copy files to the Mac, install packaged and other security features once the image is finished deploying. We used that to install some packages that will create the admin user and kickstart the Munki binary installation. Munki is a great open source project that is widely used and provides you with an internal “App Store” on the Mac with company approved software. We would also copy a few files over to avoid running around with a USB drive and copying the default wallpaper.

Munki opened so many options for us! We used to rely on Apple Remote Desktop to install things remotely, but this creates many checklists and was not prone to errors. With Munki you can create different lists of packages and configurations that it will apply consistently. We had separate lists for different departments too. We could also update the software for the whole company or a specific department. Running scripts is also an option so you if you want to use the defaults command to set settings or bash CLI that will work correctly.

If you are using an MDM, one more step you can do is enroll your Macs using a quick add package. I prefer doing that at the Deploystudio level (not Munki), so I can be sure that once a Mac finished without errors, it is now enrolled.

To speed things you should use a wired cable an create a separate VLAN only for the deployment purposes. It is possible to use an external drive and that might speed things up however this is a single point of failure. Also if it takes 5 min or 30, it does not make that much of a difference as long as you don’t need to be there pushing buttons and clicking things.

So now you have a Mac, with the latest OS, enrolled to your MDM, connected to Munki, pulling all the apps and setting. We put a printed page with the first-day instruction inside the laptop and back in the box it goes, waiting for the new owner to open it up.


You get some indication from Deploystudio that things ran successfully, but that was pretty much it so far. We needed a solution to monitor the status of the Macs and let us know if something is going wrong. After testing several options, we decided to use Watchman Monitoring. It was everything we needed for a reasonable price.

This service is fantastic at what it does:

  • Asset tracking
  • Hardware and software information
  • Warranty details
  • Notification on errors

You can get notifications for:

  • Kernel Panic
  • Computer name or OS changes.
  • OS downloads
  • Full HD

We could customize the alerts to our liking and open a ticket to our helpdesk software for those situations when we want to follow up.

That is how it used to work, but then Apple came in and had to change things…