40

This article describes a bug where entering root when prompted for an unlock allows any user to unlock system preferences. It warns that:

There’s no need to do this yourself to verify it. Doing so creates a “root” account that others may be able to take advantage of if you don’t disable it.

The article does not describe what to do if an over-eager engineer reproduced the problem and now needs to remove or disable the root account.

How can this account be safely disabled or removed?

This Apple page describes how to disable the account but this does doesn't protect against the fault because the fault can just re-enable the account. It will work to restore the system to its normal state with root disabled once the security bug is fixed.

Update 2017-11-29 16:43 UTC

See About the security content of Security Update 2017-001 to update macOS High Sierra to protect from bypassing administrator authentication without supplying the administrator’s password.

  • The title of this question is an XY as currently stated, as removing or disabling the account is not desired. – Monty Harder Nov 30 '17 at 20:58
40

Patch available, click here, or just update on the machine

Interestingly enough there is no patch for the beta and developer versions of OSX yet as far as I know. I'll update this answer as soon as I hear of them.

Download the patch above. Leaving the rest of the post for history :-)

The CVE is CVE-2017-13872 and NIST will update the analysis in the near future.

Original answer, relevant without patch

First off, do not disable the root account via the GUI, having a "disabled" root account is the cause of the problem.

You shall enable the root user and give it a password. This is important, since the vulnerability is available remotely as well, via VNC and Apple Remote Desktop (to name a few)(another source).

There are two basic ways to do this; GUI and terminal.

First off, GUI

To enable the root account, go to "Directory Utility", ie cmd + space and search. Press the lock to unlock "admin mode", then enable the root account through edit -> "Enable Root User".

How to enable root

It should ask for a root password, for now enter your normal password (so you don't forget it). If it doesn't ask for a password, use Edit -> "Change Root Password..." above.

Terminal

If you are more of a terminal person, use the below:

sudo passwd -u root
## Enter passwords as needed.... 
## (if you are using the terminal you should know what you are doing...)

This is enough with a terminal, the problem with the GUI way is that we have to enable the account to set a password, which we don't have to with the terminal.

Notes

Even if you have a password set for the root account your computer it will become vulnerable if you disable the root account. The action of disabling the root account seems to be the culprit. So I repeat, the root user should be enabled and have a password if using the GUI, whilst via terminal only using ´passwd´ is "ok" (although this state is unreachable via only the GUI). It seems that the "Disable Root User" in "Directory Utility" removes the password for the root account, in a sense giving you a password-less root account which is vulnerable.

It seems like trying to log in with "root" in a systems login-window enables the root account if it is disabled previously. Ie with a disabled root account you need to enter root twice in a systems login-windows to gain root access, and (according to my testing) on the first try the root account is enabled (with no password if not set via passwd), and on the second try you go through.

It seems that the issue has been in the open since at least 2017-11-13 (13th of November), when it is mentioned in the Apple support forum.

Please prove me wrong, I would really appreciate to be wrong right now.

Scary update

After enabling the passwordless root account (i.e. through the system preferences panel and clicking a "lock" and entering "root" with blank password one, two or three times (number of times depends on initial state)) it is possible to log on to the computer from the main login screen using "root" and a blank password (!). SSH / Telnet does not seem to work, but Apple Remote Desktop, Screen Sharing and VNC are vulnerable.

So for networks admins it might be of interest to temporarily drop packets to the following ports:

  • 5900-5905(ish, to be ninja safe) to get the most common VNC ports. VNC starts at 5900 by default and enumerates upwards if you are using multiple displays (uncommon though). Screen Sharing and Apple Remote Desktop also seems to use these ports (list of Apple software ports)
  • 3283 and 5988 for Apple Remote Desktop (list of Apple software ports)

Additional reading:

A valiant attempt to reference other sources dealing with the issue. Do edit and update my answer if you have more.

  • 5
    Ok I see why the self-answer is wrong. Disabling root does no good until this fault is fixed since the fault itself will just re-enable the account. Have some upvotes so you can comment! – Freiheit Nov 28 '17 at 22:12
  • 1
    I'm not a mac guy, but in the *nix world, disabling the root password should not be any less secure than having a secure password. In fact, it is very common to disable the password and to set the shell to /dev/null for root. In this way access to root account occurs through su syscalls for users with that permission. – crasic Nov 29 '17 at 0:13
  • 1
    @crasic AFAIK OSX does something weird with their system-login windows. They apparently enable accounts in general or root in specific if tried. And there is virtually no documentation available of this behaviour. Do note that the BSD specifics (ie commandline / bash usage) is unproblematic. – flindeberg Nov 29 '17 at 5:17
  • So with the Terminal command, you can set the root password without enabling root? That seems the most secure option. – wisbucky Nov 29 '17 at 7:16
  • 1
    @jcm Nah, it actually isn't it's just very badly worded after moving the text around a bit. I'll try to clear it a bit, have look in a min? – flindeberg Nov 29 '17 at 11:43
10

If you can’t install the official patch or don't want to trust that it worked, then

You don't want to disable root user on High Sierra only.

To secure your Mac, enable root with a long secure password.

We are not changing this at work until the next full point release is out for macOS which would likely be 10.13.2


Unless you take action, root user is disabled out of the box and this is bad if your Mac isn't patched correctly.

If you want, optionally harden the shell until Apple has an official patch or fix.

Here is a great script to set a random root password and change / set the root shell to /usr/bin/false so that even if the password is guessed, the root shell can't log in:

It basically does three key things:

rootpassword=$(openssl rand -base64 32)
/usr/bin/dscl . -passwd /Users/root "$rootpassword"
/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false

The UserShell create is if the shell is not set, and the full script checks for an existing shell and -changees it instead of -createing it.

How do I protect myself from the root vulnerability in macOS High Sierra?

  • 1
    It's generally preferable to not store a password even temporarily like this. The dcsl man page suggests "do not provide the password as part of the command and you will be securely prompted" – Josh Caswell Nov 29 '17 at 14:30
  • 1
    Agreed @JoshCaswell - having it in a script is better since the variable isn’t exported and it’s generated. The good news is Apple has an official patch that makes this hack a short lived necessity - we ran this as a prophylactic to the much greater harm of hard coding the same password across the fleet or having no password at all. It was surely a compromise and not a solution. – bmike Nov 29 '17 at 18:57
  • Out of pure curiosity, why do you have a link to this question at the end of your answer? – reirab Nov 29 '17 at 23:21
  • 1
    @reirab totally messed up. See edit to fix the proper link. Thanks! – bmike Nov 29 '17 at 23:34
2

Run a software update from the App Store. Apple released a security update this morning.

0

You need to log in as the root user and change the password to something strong. If it actually creates a new account (as opposed to enabling the already existing root account) you should delete that account first.

  • See my self-answer. Your advice to set a strong password is reasonable but entirely disabling the account seems like an even more rigorous protection and restores OS X to its default state. support.apple.com/en-us/HT204012 . Would setting a strong password guard against exploiting the described bug even if the root account is re-enabled? – Freiheit Nov 28 '17 at 22:03
  • On High Sierra, 10.13.0 and 10,13.1, you absolutely do not want to disable the root account. The problem is that if root is disabled and you attempt to use any Login Window to log in as root, Login Window will enable the root account with a blank password. If root is already enabled with a strong password, Login Window does not erase the password. The only mitigation is to enable root with a strong password. – Brian Reiter Nov 29 '17 at 12:19
0

Apple just released an update to fix the issue.

Security Update 2017-001 https://support.apple.com/en-us/HT208315

Also to prevent unauthorized access to your Mac computers, you should enable the root user account and set a password specifically for the root user.

https://support.apple.com/en-ph/HT204012

If your root user account is active already, make sure that you change the password just to make sure that the blank password vulnerability isn't set.

0

No! Do not remove the root account!

First of all, root has been present in all versions of macOS, Mac OS X, Mac OS, and even ancient versions of the operating system. macOS did not recently create this account because of a vulnerability. It merely exposed it by accident.

Removing root would be a very bad idea, and let me tell you why.

It would completely cripple macOS, since there would be no account with enough privileges to run critical services (such as WindowServer, which runs the GUI). There are safeguards in place to prevent clueless users from removing root, and you should not attempt to bypass them.

Let's find out who runs the very first processes in the system, the most important processes (using Activity Monitor):

kernel_task and launchd are owned by too

Hey, it's our friendly neighborhood root again! The first process (with PID 0) is actually controlled by the kernel, and will probably have full permissions anyway, but its child process, launchd (responsible for starting services such as the login window and window server itself) is started with the privileges of root. If root didn't exist, this process would have never started, or would have no permissions.

Securing the root account

Other answers have provided a patch released by Apple that should fix the issue. However, if you are unable or non-willing to install it...

It works because macOS re-hashes the entered password as an "upgrade" because the disabled account (root) was incorrectly detected as having an old hash. It will still say it's incorrect, but the next time, the hashes will match (because macOS changed it) and it will let you in.

To secure root, you'll have to use Directory Utility. There are two ways to access it:

  1. Use Spotlight. Starting Directory Utility using Spotlight
  2. Use Finder. Open Finder, press Command+Shift+G (or select , enter in /System/Library/CoreServices/Applications/, and press Go (or hit Enter). Then open Directory Utility from there. Selecting Go Selecting where to go Opening Directory Utility

Once you've opened Directory Utility, you'll have to click the lock to make changes

After you've done that, select Change Root Password or Enable Root User from the Edit menu. I show Change Root Password since my root account is already enabled with a strong password.

Selecting Change Root Password

Choose a password, and now the blank password won't work anymore.

Choosing a password

Congratulations! You are no longer vulnerable to the root hack.

  • "Guessing by pure speculation, the system probably re-enables the root account because you entered in the correct password (blank in this case). " -- not quite right. There's a migration path to update passwords using an old hashing mechanism, and it doesn't handle ! (which, as a UNIX type, you'll probably recognize) correctly. – Charles Duffy Nov 30 '17 at 22:17
  • See objective-see.com/blog/blog_0x24.html for a root-cause analysis. – Charles Duffy Nov 30 '17 at 22:31
  • Right - so my speculation wasn't accurate. So it re-hashes a blank password as an "upgrade" because the disabled account was incorrectly detected as having an old hash? Am I correct? – Dev Dec 5 '17 at 2:14
  • In theory, what it's supposed to do in this codepath is check that the old hash algorithm validates the entered password, and then update with a new hash (of the entered password, which is known to match the old one). In practice, it doesn't check for errors from the function that's supposed to retrieve the old hash from the "ShadowHash" field (or, rather, it checks only the return value, but not the passed-by-reference value used to return the comparison result), and then generates a new hash from the password (empty or not!). – Charles Duffy Dec 5 '17 at 2:42
  • ...so, pretty much, yes, you're correct. :) – Charles Duffy Dec 5 '17 at 2:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .