⌘ MacBlog

On Root

by Matthew Warren

Today was a very bad day for Apple. @lemiorhan tweeted a severe security vulnerability affecting all current versions of macOS High Sierra. A simple procedure allowed any user to perform a trivial root privilege escalation. Yikes. So how do we mitigate it?

The Vulnerability

The default configuration of macOS leaves the root user disabled. This is generally a good security practice. However, in macOS High Sierra (10.13), any user can enable the root account and set an arbitrary (or blank) password. One easy "attack" (if you can call it that):

The root account is now enabled and configured with a blank password. Alternatively, any value entered in the password field would be accepted and set as root's password.

You can now log out, then log back in as root at the login window.

More info at MacRumors.


As a temporary workaround:

  1. Enable the root account
  2. Set a random password for root
  3. Leave root enabled and wait for Apple to issue a fix

Rich Trouton has a script and accompanying blog post to deploy the workaround to your clients. Rich's script also set root's shell to /usr/bin/false to prevent logins.

I've also made a slight modification to error-check the password setting operation. This helps me when reviewing policy logs in Jamf.

To be clear, this does not fix the problem, merely works around it to prevent a malicious actor or curious user from escalating to root.


What versions of macOS are affected? All versions of macOS High Sierra 10.13. This includes 10.13.0, 10.13.1, and all current betas of 10.13.2 (betas 1-5).

All previous versions of macOS are unaffected.

Should the root account be disabled after setting a password? No. Leave the account enabled for now, until Apple releases a fix. If you disable the account, the bug will be able to re-enable it and reset the password.

Can this be exploited remotely? Yes. Certain sharing and remote access configurations can allow this to work remotely. For example, attempting to authenticate as root twice over VNC will trigger the bug.

Can this be exploted using SSH? No. SSH appears unaffected.

Is this the extent of the problem? Currently unknown. This is an ongoing vulnerability and we don't definitively know the extent.

Mitigate it now.


Ross Derewianko documented details as they were discovered.

Everyone in the MacAdmins slack #security channel who participated in this fire drill.

← Previously:
How to Manage Only Filevault Recovery Key Escrow with Jamf Pro
Afterward: →
Off Root