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 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):
- Open System Preferences and click Users & Groups
- Click the lock icon to unlock the preference pane
- Type "root" in the username field
- Click the password field to give it focus, then press Enter to "Unlock"
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
You can now log out, then log back in as
root at the login window.
More info at MacRumors.
As a temporary workaround:
- Enable the
- Set a random password for
rootenabled 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.
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.