Skip to content
Naked Security Naked Security

Apple’s “blank root password” fix needs a fix of its own – here it is

Bug, fix, bug, fix - but we're still saying "Well done" to Apple for a superquick response to the "blank root password" vulnerability.

If you’ve ever been hiking in California’s High Sierra, you’re probably in awe not only of its spectacular nature but also of its many, tricky, rocky pathways.

It’s beautiful but it can bite you.

That’s pretty much how Apple must be feeling this week about its own High Sierra, the tradename of its latest 10.13 version of macOS.

News broke early in the week that the macOS authentication dialog could be used to trigger an all-but-unbelievable elevation-of-privilege vulnerability.

We’re calling it the “blank root password” bug.

The bug explained

Not just anyone can make critical configuration changes on your Mac, such as turning off the filewall or decrypting your hard disk.

Many changes need to be authorised by a user with Administrator privileges – and even if you’re already logged in with an Admin account yourself, you need to authenticate again every time you want to do something administrative.

That’s why many System Preferences panes, for example, feature a padlock you have to click if you want to make changes:

Turns out that if you changed the User Name field to root, the all-powerful superuser account that is never supposed to be used directly, and entered a blank password once…

…then the root password somehow actually ended up changed to a blank password, so that when you entered a blank password for the root account thereafter, it Just Worked.

Quite what sort of coding bug led to the bizarre situation that testing a password ended up modifying that password is something Apple isn’t saying.

As security blunders go, however, it’s a bit like giving an immigration officer a false date of birth, only to find out, when he opens your passport to catch you out in the middle of your lie, that your passport has miraculously reissued itself with your “new” birthday.

Faster and faster

Four years ago, Apple notoriously took more than six months to fix an authentication vulnerability in the sudo command, the program that sysadmins rely upon to maintain the security of privileged administrative tasks performed at a command prompt.

But Apple has come a long way in responsiveness since then, and this week’s “blank root password” bug was patched within about one day by the new-look Apple.

We wrote about the patch yesterday afternoon and wholeheartedly said, “Well done to Apple for acting quickly.”

When we said those words, we were well aware that such a rapidly-issued patch might have unintended side-effects, especially when the changes involved a system component associated with password verification and administrative authentication.

We wondered to ourselves whether Apple’s patch might end up with some system features inadvertently de-authenticated…

…but we said “Well done” to Apple anyway.

We figured that, in most cases, requiring some legitimate users to re-authenticate is far better than letting any crooks wander in unauthenticated.

And we stand by those words even now we know that there has been at least one “inadvertent de-authentication” problem caused by yesterday’s patch, a side-effect that could stop file sharing working on your Mac:

If file sharing doesn’t work after you install Security Update 2017-001, follow these steps. 

[. . .]

1. Open the Terminal app, which is in the Utilities folder of your Applications folder.
2. Type sudo /usr/libexec/configureLocalKDC and press Return. 
3. Enter your administrator password and press Return.
4. Quit the Terminal app. 

The command above, /usr/libexec/configurelocalKDC, isn’t needed often – it’s used to set up what’s known as a Kerberos Key Distribution Centre (KDC). (The prefix sudo tells macOS to run the configurelocalKDC command with Administrator privileges, which is why you need your admin password.)

The good news is that you don’t have to know exactly what that means – but, greatly simplified, Kerberos is the authentication system used for Windows-style file sharing, and the KDC is the background process that is responsible for checking that you’re authorised to use the shares you try to access.

Configuring this KDC thing is usually done for you, handled automatically when you setup your Mac; after yesterday’s emergency “blank root password” update, the KDC needs to be configured again, and that means you need to provide an administrative password to complete the task.

It’s unfortunate that this happened, but the fix for the fix is pretty simple: we think that if you can launch a mail application and paste text into the subject line of a new email, you’ll have little or no trouble with this one.

So we’re repeating our “Well done” to Apple for getting a fix out quickly.

The “blank root password” bug was publicly disclosed, which pretty much forced Apple’s hand to respond at once, and it did.

Some of us will need to put in our admin passwords to get file sharing working again, in return for all of us being rapidly protected against a widely-publicised security hole.

As far as “taking one for the team” goes, we’re comfortable with the balance in this case.


It’s also worth noting that Apple replaced the original “fix” as well so this step is only needed if you got initial fix before Apple found this issue and replaced the update.
Per MacRumors:
Update: Apple appears to have released a revised version of the security update, which is valid for systems running both macOS 10.13.0 and 10.13.1. The revised version may also address the issue in the original version that resulted in file sharing problems.


Curiouser and curiouser. I haven’t had a second Security Advisory email from Apple; I have yesterday’s update showing as installed; and I have the updated file that Apple lists in its support article (opendirectoryd-483.20.7) as a way of checking that the update worked.

Yet I have a new Security Update waiting for me on the App Store, listed with the same number as yesterday (2017-001).

Waiting for that one to install now. Maybe the binary files actually installed in the update are the same but the install script is different (e.g. it automatically runs the necessary configureLocalKDC command this time round)…


…yep, the second update-with-the-same-name just finished. I still have opendirectoryd-483.20.7, and I now have two updates called 2017-001 listed in my App Store log.

A second Security Advisory email from Apple about the second update-with-the-same-name would be really helpful…


Thank you for this. I’ve been wrestling with this problem most of the afternoon until I saw this post. Now all is well.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!