Main navigation

Major vulnerability in High Sierra 10.13.1: anyone can gain elevated privileges (updated)

TL; DR Summary:
If you are running High Sierra, stop whatever you are doing and enable the root user, assigning it a secure and robust password. If you don’t, anyone is likely to be able to gain privileged access to your Mac without knowing any usernames or passwords.

How to do that

Log onto your Mac as an admin user, open the Users & Groups pane, and authenticate as that admin user. Click on Login Options at the lower left, and click on the Join button by Network Account Server in the lower section of the pane. In the next dialog, click on the button to Open Directory Utility, then click on its padlock and authenticate again.

If the root user is not enabled yet, use the Edit menu command to enable it, and assign it a secure and robust password.

If the root user is already enabled, use the the Change Root Password… command in the Edit menu to assign the root user a good password. Quit Directory Utility, and close the Users & Groups pane.

Oh, and Patrick Wardle believes that this can be exploited remotely, if you have certain sharing services enabled. So even if you think that physical access to your Mac is restricted, it’s quite possibly still vulnerable.

Here’s how this story developed this evening…

This evening, Lemi Orhan Ergin has revealed a major security vulnerability in macOS 10.13.1 High Sierra, in which any local user can obtain elevated privileges without knowing any username or password.

The key part of this vulnerability is that repeatedly entering the username root with an empty password into authentication dialogs can eventually result in successful authentication. This can even be performed when using a guest account!

A simple demonstration is to enable the guest account in Users & Groups, log out, and then log back in as the guest user. Open a pane in System Preferences which usually requires authentication, such as Users & Groups, or Network. Then click on the padlock to bring up the authentication dialog. There, enter the username root, leave the password blank, and click on the Unlock button.

The first time that you do this, there will be a pause, and the dialog will shake to indicate refusal. Keep trying, and after 3-6 attempts, the pane will suddenly unlock, and give you admin access to its controls.

While Apple works out how to fix this and promulgates an urgent update, High Sierra users should therefore disable guest accounts (that is strongly recommended anyway, but check that yours is), and ensure that unattended Macs are left with the user logged out fully. Hopefully the latter will not prove vulnerable to the same exploit.

Anyone using High Sierra systems to store and process sensitive information might like to re-evaluate their security measures very quickly.

In case Sierra users are concerned that this might affect older macOS, I have tried it on Sierra 10.12.6, and it definitely doesn’t work there: the behaviour of the authentication dialog is quite different, responding slowly and shaking each time. Phew!

Update at 2045:

The suggested workaround seems to be to leave the root account enabled, but to assign it a secure and robust password – thanks to Jack Brewster via Andy Ihnatko.

In practice, until a High Sierra system is protected from this:

Anyone can start up and access any Mac (unless it is firmware-protected, or the startup volume encrypted) simply by logging on as root with an empty password. This then gives then admin rights, at least.

Anyone can bypass an authentication dialog in macOS, such as that protecting System Preferences panes, simply by entering the username of root and an empty password. This works from guest accounts too.

Some access following authentication as root appears fragile, and may not work fully. But a local intruder still has a lot more access to your Mac than you’d want.

It is also much easier to use this exploit to access a Mac if the Login options (in Users & Groups) are set to display the login window as Name and password, rather than a List of users.

Although some have suggested simply disabling the root account would block exploits, that doesn’t currently look to be the preferred workaround.

Ultimately, this is going to require an urgent software update to restore system security.

Update at 2115:

The preferred workaround for this does seem to be to assign the root user a secure and robust password. To do this, log onto your Mac as an admin user, open the Users & Groups pane, and authenticate as that admin user. Click on Login Options at the lower left, and click on the Join button by Network Account Server in the lower section of the pane.

In the next dialog, click on the button to Open Directory Utility, then click on its padlock and authenticate again. Then use the the Change Root Password… command in the Edit menu to assign the root user a good password. Quit Directory Utility, and close the Users & Groups pane.

It is currently unclear whether there is a separate security vulnerability involved here, or whether this is ‘just’ a default misconfiguration of High Sierra. Sierra, in contrast, ships with the root user disabled, which has been standard practice for OS X and macOS in the past.

We will have to wait for further information from Apple confirming the problem and the official recommended solution.

Update at 2135:

The smart money is now on this being a bug in High Sierra, and not a simple misconfiguration. According to MacFormat @MacFormat, High Sierra systems are not configured by default to enable the root user. However, entering the username root and a blank password (as described above) triggers a bug which then enables the root user with that blank password.

This will therefore require an urgent security fix from Apple, and assigning a secure password to the root user is only a temporary workaround. Note also that MacFormat staff have been able to exploit the bug to gain access to a Mac as the root user over a local network, which makes it even more serious.

14Comments

Ever since installing High Sierra I have noticed the Root user become enabled now and again. I first stumbled on this after seeing the Other option pop up on the login screen. You can disable the Root user in Directory Utility (at /System/Library/CoreServices/Applications), which I’ve done every week or so since installing High Sierra. No clue why it gets enabled again and again. I hadn’t actually tried using it, though, when enabled. I guess it is being turned on with no password, given what you’ve written here. Really bad major vulnerability indeed. But at least you should be able to stop it by disabling the Root user yourself again and again. Let’s hope this is fixed in the next update to High Sierra.

Thank you for your helpful comments. I have updated the article above with the latest news, which indicates that this is a bug, which is going to need a software patch. The actions described above trigger the bug, which activates the normally disabled root account with a blank password.
So the best workaround for the moment is to enable the root account (if you don’t, an intruder can) and assign it a robust and secure password.
Howard.

Thank you, Miles – I have seen the tweets showing this.
It’s such a staggering vulnerability that I don’t think that anyone recognised its significance at the time.
As for blockquotes, the official WordPress comment markup is <blockquote>, and demonstrated below.

Thanks Howard! The blockquote display in the email notification was correct (or rather, what I would expect), while the styling on the website is quite a bit larger. I recall when I last used the blockquote tag you kindly cleaned up the display. No worries, I’ll just avoid the tag here for now. Thanks again.

Simon,
I have tested Sierra 10.12.6, and it definitely does not occur there. I’d be confident that it does not occur in El Capitan either. All the evidence is that it is new with High Sierra 10.13, and present in 10.13.1 too.
Howard.

Yes, except that you need to enable remote access via ARD (and similar) in order to open those vulnerable accounts.
So long as you don’t enable those, they’re not exploitable.
But yes, this is a security calamity. It’s as if someone when testing High Sierra opened this up deliberately, and forgot to close it down. Staggering.
Howard.