Share this story

Update 11/29/2017 9:47 AM California time: Apple patched the flaw on Wednesday morning. Installing the patch immediately is the best way for Mac users to protect themselves and supersedes any mitigation advice. What follows is the story as written before the patch was available.

In one of Apple's biggest security blunders in years, a bug in macOS High Sierra allows untrusted users to gain unfettered administrative control without any password.

The bypass works by putting the word "root" (without the quotes) in the user name field of a login window, moving the cursor into the password field, and then hitting enter button with the password field empty. With that—after a few tries in some cases—the latest version of Apple's operating system logs the user in with root privileges. Ars reporters were able to replicate the behavior multiple times on three Macs. The flaw isn't present on previous macOS versions.

The password bypass can be exploited in a variety of ways, depending on the way the targeted Mac has been set up. When full-disk encryption is turned off, an untrusted user can turn on a Mac that's fully powered down and log in as root. Exploiting the vulnerability was also not possible when a Mac was turned on and the screen was password protected. Even on Macs that have filevault turned on, the bypass can also be used to make unauthorized changes to the Mac System Preferences (including disabling filevault), or the bypass can be used to log in as root after logging out of an existing account but not turning off the machine. The behavior observed in Ars tests and reported on social media was extremely inconsistent, so results are likely to vary widely.

The upshot of all of this: as long as someone has filevault turned on, their files are most likely safe from this exploit as long as their Mac is turned off before an attacker gets hold of it. Locking a screen with a password also appeared to protect a computer while it's unattended.

Privilege escalation

Of more concern is that malicious hackers can exploit this vulnerability to give their malware unfettered control over the computer and OS. Such escalation-of-privilege exploits have become increasingly valuable over the past decade as a way to defeat modern OS defenses. A key protection found in virtually all OSes is to restrict the privileges given to running software. As a result, even when attackers succeed in executing malicious code, they're unable to get the malware permanently installed or to access sensitive parts of the OS.

"This looks like something that a piece of malware or an attacker could use in a multistage attack," Patrick Wardle, a researcher with security firm Synack, told Ars. In cases such as these, attackers use one exploit to run their malicious code and a second exploit to escalate the privileges of that code so it can perform actions that the OS normally wouldn't allow. "This appears to be one way malware or an attacker would be able to do that."

Amit Serper, principal security researcher at Cybereason, said his tests showed the vulnerability is located in com.apple.loginwindow, a macOS component that's one of at least two ways users can log into accounts. He said he was unable to reproduce the exploit using a Mac's terminal window, although he said he saw reports on Twitter from other people who said the bypass worked using the terminal window as well. Whatever the case, he agreed with Wardle that the flaw likely represents a major privilege-escalation vulnerability that can be exploited easily by malware developers.

"If they're using API (programming interface) calls, it's a matter of writing the appropriate code," Serper told Ars. "An attacker should be able to trigger it."

The vulnerability can also have dire consequences for people who have made their Macs accessible through remote management screen sharing provided through macOS or third-party services. Will Dormann, a vulerability analyst at CERT, said on Twitter that having remote options turned on will allow attackers to remotely access the machine with no password required. Results from a quick search that were posted on Twitter showed more than 105,000 Macs alone had the VNC remote desktop app installed. To check if remote management or screen sharing is on, users can check the Sharing menu in System Preferences.

Remember goto fail?

Further Reading

A vulnerability that logs users in as root without requiring any password at all is extraordinary, both because of the lack of testing it suggests on the part of Apple developers and the potential harm it presents to end users. The last time in recent memory Apple made an error of this magnitude was the so-called goto fail bug that gave attackers an easy way to bypass TLS encryption. It took Apple four days to patch the critical flaw, which got its name from one of the lines of code responsible for the vulnerability.

Apple representatives issued the following statement:

We are working on a software update to address this issue. In the meantime, setting a root password prevents unauthorized access to your Mac. To enable the Root User and set a password, please follow the instructions here: https://support.apple.com/en-us/HT204012. If a Root User is already enabled, to ensure a blank password is not set, please follow the instructions from the "Change the root password" section.

Specifically, users should do the following:

open the Users & Account menu in System Prefereces

click the padlock at the bottom and enter an administrator name and password

click Login Options

Click Join (or Edit)

Click Open Directory Utility

Click the padlock at the bottom and enter an administrator name and password

From the menu bar in Directory Utility, choose Edit > Change password

Enter a strong password

The most important part for now is not to disable the root account. That only allows the root account to be re-enabled by putting "root" in a user name field and leaving the password blank. Until Apple issues a patch, people should secure the root account with a strong password and leave the account enabled. As always, passwords should be at least 13 characters long, randomly generated, and contain a mixture of numbers, upper- and lower-case letters, and symbols. As an added layer of security, users should also ensure they have filevault turned on.

Promoted Comments

I must be missing something. Given physical access, how is this different from just rebooting into single user mode?

As the article says, this can also be used by software that has user-level access to gain root access to the machine (to install services, update firmware, whatever).

Second, if you're using disk encryption, reboot into single user mode isn't possible without the password. But with this bug, when you step away from your machine for 2 minutes, I can hop in, grant myself root access, create myself a backdoor and you'll never be the wiser (nor will changing your password help you).

It's highly likely that this exploit has been known by bad actors for quite some time. If they ever gained access with this method, they probably installed a backdoor. So closing the hole doesn't help at all.

Honestly, if you have had any type of remote access enabled to a Mac running High Sierra the only responsible thing to do is to reinstall MacOS fresh. Just putting in place the temporary fix and waiting for a permanent patch from Apple should not be considered enough.

This is really bad. Thankfully I already had a root password set, but I'd wager a great majority of users have not.

Edit: If there's any consolation prize, this does not work from the lock screen until after you did the root+[blank password] thing in System Prefs. So someone can't just come up to your locked machine and get in; if you system is sitting there unlocked they can activate the root account with a null password.

Someone showed this working also from command line as well as using remote management, so it's malicious utility is not limited to office hijinks and laptop thieves since it can under some circumstances be used remotely.

I used to have this mental image of Apple as a company that produced expensive but reliable devices. After seeing this and similar security fails over the past few months, that view has definitely changed. Add to that the fact that iOS has more crashes/bugs than Android.

It's pretty simple (but still sloppy) to miss something like this. I had a process run through testing happily because the SOP was enter number in field then press button, and it always worked when we tested it.It never occurred to me to test with nothing in the field. Of course once it into production...

It's pretty simple (but still sloppy) to miss something like this. I had a process run through testing happily because the SOP was enter number in field then press button, and it always worked when we tested it.It never occurred to me to test with nothing in the field. Of course once it into production...

I guess, but ever since SQL Server let you use a blank password for the default admin account, I'd have thought it would be a standard QAQC practice.

This is really bad. Thankfully I already had a root password set, but I'd wager a great majority of users have not.

Edit: If there's any consolation prize, this does not work from the lock screen until after you did the root+[blank password] thing in System Prefs. So someone can't just come up to your locked machine and get in; if you system is sitting there unlocked they can activate the root account with a null password.

The bypass works by putting the word "root" (without the quotes) in the user name field of a login window, moving the cursor into the password field, and then hitting enter button with the password field empty. With that—after a few tries in some cases—the latest version of Apple's operating system logs the user in with root privileges.

Quote:

For now, users can mitigate the vulnerability by securing their root account with a strong password

I don't get this at all. The first quote suggests that there is a bug that allows you to bypass the root password. But if that is the case, then what does it matter how strong your root password is? If the bug is instead that the default root password is empty, then why would it take multiple tries to log in?

So I take it that the root user isn't "locked" (passwd -l root) in macOS like it is in Ubuntu for instance?

In the default setup for Ubuntu and other Linux distributions, root is only accessible after issuing passwd root or by using sudo, since the first user created gets added to /etc/sudoers and/or the wheel group, not sure which atm. I guess Apple should take a peek in the Ubuntu code, unless Darwin is that much different from Linux.

So I take it that the root user isn't "locked" (passwd -l root) in macOS like it is in Ubuntu for instance?

In the default setup for Ubuntu and other Linux distributions, root is only accessible after issuing passwd root or by using sudo, since the first user created gets added to /etc/sudoers and/or the wheel group, not sure which atm. I guess Apple should take a peek in the Ubuntu code, unless Darwin is that much different from Linux.

Normally Root is disabled but if you reproduce this bug then it creates a Root user on the system that has login enabled. So if anyone is messing around trying to reproduce this, make sure you disable root afterwards, or set an actual password on the account.

Does Mac OS not implement some form of MAC (Mandatory Access Control) security? Thinking SELinux or similar. As canned as that OS config is, you'd think Apple could swing it if anyone could...

edit: to clarify MAC as in security (compared to DAC) not Macintosh...

It isn't really relevant. The flaw, from what I can see, is that the root password is empty. So anyone who requests access - whether blocked by MAC or anything else - can very simply gain it.

There doesn't actually appear to be a code issue from the description. The code works as intended: If you have the rights, you can request access. The problem is in setup/install, where they don't auto-set roots password to a random value.

So I take it that the root user isn't "locked" (passwd -l root) in macOS like it is in Ubuntu for instance?

In the default setup for Ubuntu and other Linux distributions, root is only accessible after issuing passwd root or by using sudo, since the first user created gets added to /etc/sudoers and/or the wheel group, not sure which atm. I guess Apple should take a peek in the Ubuntu code, unless Darwin is that much different from Linux.

Darwin is based on BSD, so there are some fundamental differences at the admin level. (They're probably ~95% common, but with enough differences to trip you up if you're unfamiliar.)

So I take it that the root user isn't "locked" (passwd -l root) in macOS like it is in Ubuntu for instance?

In the default setup for Ubuntu and other Linux distributions, root is only accessible after issuing passwd root or by using sudo, since the first user created gets added to /etc/sudoers and/or the wheel group, not sure which atm. I guess Apple should take a peek in the Ubuntu code, unless Darwin is that much different from Linux.

Darwin is based on BSD, so there are some fundamental differences at the admin level. (They're probably ~95% common, but with enough differences to trip you up if you're unfamiliar.)

Well also MacOS diverges from BSD with how root security works. For example, system integrity protection means some system processes are granted special entitlements and permissions that even the root user doesn't have.