Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Vulnerability 10.13 - Root

Since this is out there, and the original finder did not go through responsible disclosure. Figured i'd post it here so at least admins are aware.

Dear @AppleSupport, we noticed a HUGE security issue at MacOS High Sierra. Anyone can login as "root" with empty password after clicking on login button several times. Are you aware of it @Apple?

This works on User & Admin accounts.

That being said, if you enable root and have a password on it. You're not affected. If you don't it'll enable root and create an account.

Enabling a root password however may cause you more tech debt down the line.

Like Comment
Order by:
SOLVED Posted: 11/28/17 at 2:45 PM by dgreening

Confirmed... Escalated with my Apple SE...

SOLVED Posted: 11/28/17 at 2:51 PM by Taylor.Armstrong


SOLVED Posted: 11/28/17 at 2:51 PM by brytox

Just tried this out and not only does it let you login as root but even if you have the account disabled, it reenables it again.

SOLVED Posted: 11/28/17 at 2:53 PM by jlmorton

Did this and confirmed it happens here as well.

SOLVED Posted: 11/28/17 at 2:55 PM by dgreening

Might be good for someone to post how to enable root, set a password, and disable it again for those not in the know. ;)

SOLVED Posted: 11/28/17 at 2:56 PM by stedrow

From what we've tested so far with macOS High Sierra 10.13 and FileVault 2:

  1. When a computer boots it goes to the FileVault 2 specific login screen which won't allow you to login as the root user.
  2. If a computer logs into an account then locks the computer/sleeps the computer you get a blank username/password login, using root:blank password works in this instance and gets you into the computer, you can then use a terminal to access FileVault 2 user's home directories. It appears that the drive may not be re-encrypting on lock/sleep?
SOLVED Posted: 11/28/17 at 2:58 PM by signetmac

I can confirm that if you have already set a root password, this vulnerability will not work.

I'd already set it on my own computer and could not validate the exploit until I went to another user's computer. Then I generated a random 30 character password and pushed it to all our 10.13 computers that don't already have a root pass set.

SOLVED Posted: 11/28/17 at 3:07 PM by rderewianko

So from macadmins slack, a way to stop it from working would be to run

/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false
SOLVED Posted: 11/28/17 at 3:20 PM by rderewianko

The above being said, there are ways to still allow a user to elevate their privileges.. This is not a fix but a band aide.

The best fix is enabling a root password..

SOLVED Posted: 11/28/17 at 3:21 PM by M0J077

If anyone is testing this, it will enable the Root account on your machine, this will enable you to log into the machine as Root with no Password. Make sure to disable the account after testing:

SOLVED Posted: 11/28/17 at 3:24 PM by bentoms

Just to second that @signetmac posted

Setting the shell to /usr/bin/false is a partial fix, sadly.

Also, root can be enabled as a non-admin too.. & without GUI interaction (as in, you can write a script to make use of the exploit)

SOLVED Posted: 11/28/17 at 3:29 PM by mike.paul

Some possible means to mitigate things would be to push a Login Window config profile forcing "List of users able to use these computers" and un-check the box for "Show Other" they should not be able to login as root. FileVault login screen is already just the enabled users but if people log out of a computer instead of shutdown/start up you can have a login window that shows "Other", or if its unencrypted it may just show the blank Username/Password fields. This method does nothing for people logged into the computer enabling this via System Preferences.

Also if root is enabled you can push out a policy with the Local Accounts payload setting the root accounts password to something only known to IT and this would disable the root login with blank password.

SOLVED Posted: 11/28/17 at 3:43 PM by steve.summers

Any idea if this is applicable to 10.13 .1 OR just 10.13? Has that determination been made yet...?

SOLVED Posted: 11/28/17 at 3:43 PM by jamesandre

Would doing the following resolve the vulnerability... (I grabbed it from this thread - )

remote the AuthenticationAuthority from the user's account

dscl . delete /Users/root AuthenticationAuthority

Put a single asterisk in the password entry, thus locking the acount.

dscl . -create /Users/root Password '*'

Disable root login by setting root's shell to /usr/bin/false

dscl . -create /Users/root UserShell /usr/bin/false

SOLVED Posted: 11/28/17 at 3:44 PM by jamesandre

@steve.summers 10.13.1 is vulnerable too.

SOLVED Posted: 11/28/17 at 3:55 PM by easyedc

Stupid question - anyone tried this on Sierra?

SOLVED Posted: 11/28/17 at 3:58 PM by john.sherrod

I just tried this in Sierra and could not replicate it.

SOLVED Posted: 11/28/17 at 3:59 PM by iQadminmac

Not good. I just updated some users to High Sierra.

SOLVED Posted: 11/28/17 at 3:59 PM by rderewianko

This only happens on 10.13+

I tried to blog part of the solution process here.

SOLVED Posted: 11/28/17 at 4:12 PM by elund

Would this be a useable solution to run via Files and Processes / Execute Command in a Policy?

dscl . -passwd /Users/root 'YourPasswordHere'; dsenableroot -d -u root -p 'YourPasswordHere'
SOLVED Posted: 11/28/17 at 4:15 PM by rupenv

I would read this:

SOLVED Posted: 11/28/17 at 4:35 PM by charlesteese-mfj

I've written this script to randomize the root pass:

set NewPassword [exec openssl rand -base64 64]

spawn passwd -u root
expect "assword:"
send "$NewPassword\r"
expect "password:"
send "$NewPassword\r"

puts "\nPassword Changed."
expect eof
exit 0
SOLVED Posted: 11/28/17 at 4:43 PM by pbenware1

This appears in 10.13.1 and the 10.13.2 beta 17c79a (current until today's beta update) as well.

SOLVED Posted: 11/28/17 at 4:58 PM by guidotti

Changing the root password in the manner described by Rich has absolutely no impact on the Jamf Binary to run as 'root', correct?

SOLVED Posted: 11/28/17 at 5:00 PM by rderewianko

Correct. The binary runs under the service user you have it set to in the jss.

SOLVED Posted: 11/28/17 at 5:01 PM by signetmac

@guidotti Correct. Almost everything on your system that doesn't run as a logged in user, is kicked off by user 0 .... root. If Rich's solution kept the jamf launchdaemons from working, then the whole system would be hosed.

SOLVED Posted: 11/28/17 at 5:13 PM by ajamal

I tested the script from on a few machines and I'm getting this error on some of them - any ideas what it means exactly?

Script result: <dscl_cmd> DS Error: -14165 (eDSAuthPasswordQualityCheckFailed)<br/>passwd: DS error: eDSAuthPasswordQualityCheckFailed<br/>Changing root shell from /usr/local/bin/zsh to /usr/bin/false<br/>

EDIT: Figured it out, changed script to a hardcoded password that will always pass Apple's (TERRIBLE) password complexity rules

SOLVED Posted: 11/28/17 at 5:19 PM by adriandupre

Thoughts on creating a smart group to identify vulnerable systems? (OS >= 10.13 and root password is null)

I'd settle for a quick check to detect if the password is null...

SOLVED Posted: 11/28/17 at 5:22 PM by stas21

charlesteese-mfj's script seems to be working for me

SOLVED Posted: 11/28/17 at 5:48 PM by dgreening

Here is how I am solving it by setting a root password (using encrypted strings) as well as performing a test to make sure a password is set, and based on that, erroring out or leaving a touch file for an ext attr to pick up:

# This script will set the root password to a known value via encrypted string, check to see that a password is set, and leave a cookie.

#Decrypt String Function for account passwords
function DecryptString() {
    # Usage: ~$ DecryptString "Encrypted String" "Salt" "Passphrase"
    echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "${2}" -k "${3}"

#Encrypted strings for passwords
rootpwd=$( DecryptString "$4" salthere passphrasehere )

#Enable root user and set password
dscl . -passwd /Users/root '$rootpwd'

#Check if root password is enabled
rootpwdtest=$( dscl . -read /Users/root Password )
if [ "$rootpwdtest" == "Password: ********" ]; then
    echo "Root password set. Proceeding."
    echo "Root password not set. Exit 1."
    exit 1

#Check for Management directory and create and place touchfile

if [ -d "${managementDir}" ]; then
                    /usr/bin/touch "${touchFile}"
                    mkdir -p "${managementDir}"
                    /usr/bin/touch "${touchFile}"
exit 0
SOLVED Posted: 11/28/17 at 6:25 PM by nojorge

Does anyone know if this is remotely exploitable on computers with Casper installed? Or would it require physical access to the machine?

SOLVED Posted: 11/28/17 at 6:27 PM by BostonMac

I've tried just changing the root password and disabling the account in the GUI and the settings take. However they do not appear to survive restart.

SOLVED Posted: 11/28/17 at 6:32 PM by easyedc

@BostonMac I believe you have to leave the root user enabled with your password. I haven’t tested but think I read that.

SOLVED Posted: 11/28/17 at 6:34 PM by rderewianko

@BostonMac , @easyedc is correct if you do it via gui it's gotta still be enabled.

SOLVED Posted: 11/28/17 at 6:42 PM by stas21

@charlesteese-mfj I am thinking of using your script, but can I later overwrite randomly created root password into something else of my choosing?

SOLVED Posted: 11/28/17 at 6:44 PM by signetmac

@nojorge If you have admin users enabled for Remote Management (ARD) or Screen Sharing, it seems that it can be exploited remotely.

Twitter link to Patrick Wardle's test results

SOLVED Posted: 11/28/17 at 8:54 PM by rodgerramjet

@adriandupre I just put together this extension attribute that returns if the root password is set or not.


RESULT=$(sudo dscl . -read /Users/root Password)

if [[ $RESULT == "Password: ********" ]]; then
  echo "<result>Root password set</result>"
elif [[ $RESULT == "Password: *" ]]; then
  echo "<result>No root password set</result>"
  echo "<result>Unknown</result>"

Then I push @rtrouton's package to any users which does not have "Root password set" and are on 10.13.

I have also set it up to do a recon after the package installs, so the extension attribute should immediately get updated and fall out of scope.

SOLVED Posted: 11/28/17 at 9:07 PM by doggles

@rodgerramjet ,

FYI: that will return the first result if the root user exists at all, regardless of its password. An enabled root user with a blank pass will appear there.

Using something like the following could pare down the most-exposed Macs better, but continue reading, as I still don't think this is worth the time:

#!/usr/bin/env bash

if [[ $(dscl . read /users/root Password | awk '{print $2}') = '********' ]]; then
  if dscl . authonly root '' &>/dev/null; then
    RESULT="Root Enabled - No Pass"
    RESULT="Root Enabled - With Pass"
  RESULT="Root Disabled"

echo "<result>$RESULT</result>"

The problem here is that while you can now determine whether root is enabled with or without a password, you cannot determine whether or not that root was enabled legitimately by the user or through the Authorization Plugin exploit (since you can also create any password you want in that prompt, it does not have to be blank).

The safer move is to just randomize all root passwords on all 10.13 machines and let the edge-case users submit a ticket when they find they cant su root anymore (which they shouldn't be doing anyway -- tell them to just use sudo -s or sudo su! ). The following will pre-emptively create a 32-character cryptographically-secure pseudo-random (CSPRNG) passphrase for root:

#!/usr/bin/env bash

dscl . passwd /users/root "$(env LC_CTYPE=C tr -dc 'A-Za-z0-9_\ \!\@\#\$\%\^\&\*\(\)-+=' < /dev/urandom | head -c 32)"

Obviously, every environment is different, and this is not a hard and fast rule; there could be some extenuating circumstances in your particular environment that require an enabled root user and the productivity impact on blowing all out root user passwords is a no-go. Keep in mind, however, that you're essentially unable to differentiate between whether that root user with a password was made legitimately or by an attacker creating a backdoor.

Note: Why I'm generating a random string by redirecting /dev/urandom to tr rather than use openssl rand: For the majority of cases, both are plenty secure. This is NSA-level threat surface stuff. But I would rather share the safest of the two to make the command applicable to the most environments as possible.

SOLVED Posted: 11/29/17 at 3:05 AM by tsossong

I don't understand why we go headless chicken mode on this issue. As long as we just need to delete one file to get Admin-rights (and this is an issue since Mac OS X came out) we don't need to try to secure macOS.

SOLVED Posted: 11/29/17 at 3:46 AM by donmontalvo

@tsossong pretty sure you'd need admin rights to delete the file to get admin rights. Or am I missing something? :)

SOLVED Posted: 11/29/17 at 3:47 AM by donmontalvo

@doggles excellent script, we made a couple changes, including setting shebang to #!/bin/sh, and closing the tag in the last line echo "<result>$RESULT/result>". #etherBeerForYou

SOLVED Posted: 11/29/17 at 3:59 AM by doggles

@tsossong, the issue is that any user could screenshare to any other discoverable Mac on the network with ARDAgent running and log in as root. At least for our situation, the biggest threat vector is other employees.

@donmontalvo, good eye, closed the XML tag. Shebang won't make a difference, just a habit of mine to use /usr/bin/env bash. I try to avoid calling wih /bin/sh when the script contains bashisms ([[ ]]). Though macOS, the shells are the same except for echo -e AFAIK.

SOLVED Posted: 11/29/17 at 5:51 AM by McAdams

Great suggestions and scripts. I can confirm this is fixed in beta 4 & 5 of High Sierra.

SOLVED Posted: 11/29/17 at 7:52 AM by kcranford

Be warned. I discovered, and have confirmed on a few sites, that if you disable root the exploit returns. When you set the root password you need to keep the account enabled.

SOLVED Posted: 11/29/17 at 8:11 AM by kentmj

So is JAMF going to change their OS whitepaper that says "you should upgrade to the latest OS on day one"?

SOLVED Posted: 11/29/17 at 8:17 AM by charlesteese-mfj

@stas21 you can use the same script to later change it to a set password (just set NewPassword to a string) or use the

dsenableroot -d

command once this issue has been fixed.

SOLVED Posted: 11/29/17 at 8:27 AM by demaioj

I see a few posts here with scripts to make random passwords for root. Sorry if this sounds stupid but I'd like to make sure there is no reason I would ever need the root password? Luckily we've only had a few users upgrade to High Sierra before it was blocked.

SOLVED Posted: 11/29/17 at 8:49 AM by jstine

Why is everyone using scripts when this seems to fix the issue? Using scripts to randomize the password instead of setting a single password for everyone?

SOLVED Posted: 11/29/17 at 8:52 AM by jrwilcox

Its difficult to log in to all 16,000 macOS devices.

SOLVED Posted: 11/29/17 at 8:54 AM by charlesteese-mfj

@jstine I don't want all my devices to share a root password, I want it to be long and randomly generated.

SOLVED Posted: 11/29/17 at 9:23 AM by donmontalvo

@kentmj wrote:

So is JAMF going to change their OS whitepaper that says "you should upgrade to the latest OS on day one"?

This. :)

SOLVED Posted: 11/29/17 at 9:36 AM by rderewianko

@jstine while that way works, it doesn't tell the root user to use a different shell. That way would also show the user at a login window, while enabling it through CLI should not.

SOLVED Posted: 11/29/17 at 10:08 AM by donmontalvo

@McAdams wrote:

Great suggestions and scripts. I can confirm this is fixed in beta 4 & 5 of High Sierra.

Are we sure? Doesn't seem to be.

SOLVED Posted: 11/29/17 at 10:11 AM by rderewianko

It is not fixed in beta 4/5. I've seen a lot of reports saying no.

SOLVED Posted: 11/29/17 at 10:21 AM by gersteina1

Just got an email from Apple:
APPLE-SA-2017-11-29-1 Security Update 2017-001

Security Update 2017-001 is now available and addresses the

Directory Utility
Available for: macOS High Sierra 10.13.1
Not impacted: macOS Sierra 10.12.6 and earlier
Impact: An attacker may be able to bypass administrator
authentication without supplying the administrator’s password
Description: A logic error existed in the validation of credentials.
This was addressed with improved credential validation.

When you install Security Update 2017-001 on your Mac, the build
number of macOS will be 17B1002. Learn how to find the macOS version
and build number on your Mac at

If you require the root user account on your Mac, see for information on how to enable
the root user and change the root user's password.

Information will also be posted to the Apple Security Updates
web site:

SOLVED Posted: 11/29/17 at 10:21 AM by keaton.svoma

Security Update 2017-001 is out that fixes the issue. No reboot is required.

SOLVED Posted: 11/29/17 at 10:23 AM by john.sherrod

Apple now has a patch out:

SOLVED Posted: 11/29/17 at 10:30 AM by MandyDroid

Yay for patches - life contiunues...

SOLVED Posted: 11/29/17 at 10:31 AM by jhuls

Until I can test something firsthand it's tough to trust anyone here who says it's been fixed. As an example I'm seeing people report that they can't reproduce the exploit but I'm guessing they're only trying to do it one time. When I tested yesterday, I initially couldn't reproduce the bug until I tried it more than once. This was the case each time I disabled root and tried it again. It always took more than one attempt.

SOLVED Posted: 11/29/17 at 10:45 AM by gersteina1

But the fix only applies to 10.13.1.

SOLVED Posted: 11/29/17 at 10:51 AM by mm2270

Would have been nice if Apple made the fix available to 10.13.0 systems as well, since not everyone may be on 10.13.1 at this point. If anyone has any users still on 10.13.0, you'll need to get them or force them to update to 10.13.1, which involves a reboot of course, and then push the security update to them.

SOLVED Posted: 11/29/17 at 10:52 AM by Taylor.Armstrong

I think this is a big enough issue to warrant upgrading to 10.13.1 out-of-band if necessary.

We're still on 10.12, so not affected, but I'd do a .1 update in a heartbeat to resolve this if we were.

SOLVED Posted: 11/29/17 at 10:53 AM by hessf

Has anyone found a pkg download of 2017-001 to push out with JAMF?

SOLVED Posted: 11/29/17 at 10:57 AM by keaton.svoma

@hessf It can be downloaded here. - Source

One thing to note is this update will be downloaded and installed automatically on all Macs running 10.13.1 so you should not need to push it out with Jamf.

SOLVED Posted: 11/29/17 at 11:03 AM by hessf

@keaton Thanks.

Will it be automatic because it's supplemental? I manually installed at the CLI on my High Sierra reference computer where automatic software updates are off.

SOLVED Posted: 11/29/17 at 11:09 AM by keaton.svoma

@hessf From my understanding it will get installed either way.

Source 1, Source 2

SOLVED Posted: 11/29/17 at 11:20 AM by abtsux

Is there a reason why you wouldnt just create a policy that uses the built in ability to reset an account password instead of using a script?

SOLVED Posted: 11/29/17 at 11:26 AM by alexjdale

For some reason I can't seem to install the update from the command line. The softwareupdate command will show me the update when I get a list of available updates, but when I go to download or install it, it says it doesn't exist.

SOLVED Posted: 11/29/17 at 11:37 AM by mm2270

@alexjdale Seeing the same thing. It shows up in a very odd way on the command line. There's an extra - at the end of the update name, as if it's missing some extra characters. I tried it several different ways, with/without the dash, with/without both single and double quotes around the update name. Fails every time saying "No such update". Oy.
I haven't tried doing just a sudo softwareupdate -ia to install everything yet, but that may work (or may not). What a mess.

SOLVED Posted: 11/29/17 at 11:56 AM by alexjdale

Yup, I wonder if it's a catalog issue on their end? I hope their forced update process works well.

SOLVED Posted: 11/29/17 at 12:00 PM by jedi1yoda1

The command I used for getting it to work within the Software Update CLI:

softwareupdate -i "Security Update 2017-001- "

It seems there is an extra space at the end of the label.

SOLVED Posted: 11/29/17 at 12:19 PM by alexjdale

Nice find, that was it. Too bad my usual patching script can't handle trailing spaces, but that's fixable.

SOLVED Posted: 11/29/17 at 12:53 PM by kquan

if you run on terminal for high sierra, it should/could be sudo softwareupdate -dia

once applied, you can confirm on terminal using sw_vers :

Should output something like :

ProductName: Mac OS X ProductVersion: 10.13.1 BuildVersion: 17B1002
SOLVED Posted: 11/29/17 at 1:01 PM by mjhersh

Perhaps this is all moot now that Apple's patched, but I wrote a shell script that can be used as an extension attribute. It detects one of 5 states of machines:

  1. "Not affected" - not running High Sierra
  2. Patched - Running High Sierra, already has Apple's security update
  3. Vulnerable - Running a vulnerable OS, but not yet exploited
  4. Exploited - Running a vulnerable OS and someone has already exploited it
  5. Secure - Running a vulnerable OS, but secured through other means (like rtrouton's script)

dscl . -read /Users/root passwd will return * on a machine with no password set for root and ******** on a machine with any password (including a blank password) set. So if it's just * on a vulnerable OS, I know the system is vulnerable but not yet exploited. If it's been exploited, that password would be set and it would show ********. If that's the case, I attempt to authenticate as root with a blank password to see if the machine is exploited or secured.

I hope someone finds this useful.

buildver=$(/usr/bin/sw_vers -buildVersion)

if [[ "$(/usr/bin/sw_vers -productVersion)" != "10.13"* ]]; then
    # Not High Sierra, so not affected
    echo "<result>Not affected</result>"
    exit 0
if [[ "$major" > "17B" ]] || ( [[ "$major" = "17B" ]] && [ "$minor" -ge 1002 ] ); then
    # Already patched by Apple
    echo "<result>Patched</result>"
    exit 0
if [ "$(dscl . -read /Users/root passwd | awk '{print $2}')" = '*' ]; then 
    # Vulnerable, not yet exploited
    echo "<result>Vulnerable</result>"
    result=$(sudo -u 'nobody' /usr/bin/osascript -e 'do shell script "/bin/echo Exploited" user name "root" password "" with administrator privileges' 2>/dev/null)
    if [ "$result" = 'Exploited' ]; then
        # Vulnerable and already exploited 
        echo "<result>Exploited</result>"
        # On vulnerable OS, but already been secured through other means
        echo "<result>Secure</result>"
SOLVED Posted: 11/29/17 at 2:26 PM by matin

Apple just released a security update for this issue.

SOLVED Posted: 11/29/17 at 2:36 PM by Taylor.Armstrong

Read up, matin! ;) . (released at 8:00 this AM)

SOLVED Posted: 11/29/17 at 2:47 PM by scharest

Anybody know a way to create a Smart Group to verify if the patch was installed on systems?

SOLVED Posted: 11/29/17 at 2:58 PM by mm2270

@scharest Per the Apple support article detailing the patch, the new OS build version will be "17B1002", so you can use the "Operating System Build" criteria to build a Smart Group that has build "17B1002" installed. That should group machines that have the patch applied.
If you want the reverse, i.e, machines running High Sierra but don't have the patch installed, use these:

Operating System Version | greater than or equal | "10.13" and Operating System Build | is not | "17B1002"
SOLVED Posted: 11/29/17 at 3:04 PM by mister2

If anyone is looking for an link from Apple to download the security update.

SOLVED Posted: 11/29/17 at 3:19 PM by txhaflaire


i used below article to deploy that one specific update.

SOLVED Posted: 11/30/17 at 8:14 AM by musat

I just rebooted my Mac and the BuildVersion is now 17B1003. It looks like they re-released the patch.

Security Update 2017-001

Looks like the original patch broke other things:

SOLVED Posted: 11/30/17 at 8:29 AM by Taylor.Armstrong

The re-release also applies to 10.13 (vs. 10.13.1).