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.
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.
The bug came to light Tuesday morning when a Mac user contacted Apple support representatives over Twitter:
— Lemi Orhan Ergin (@lemiorhan) November 28, 2017
Remember goto fail?
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.
Some people have reported they're unable to update their Macs using the instructions supplied by Apple. As others have pointed out, another way users can set their root password to do the following:
- open a terminal window
- type 'sudo su' – use your own password to authenticate. You are now root.
- Type 'passwd' and change follow instructions on screen to change the password
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.
Some researchers are speculating unsecured root account doesn't exist until someone with physical access to the Mac attempts to log in while leaving the password blank. That has prompted advice Mac users not test their systems lest they create a persistent root user account that wasn't there previously. Other researchers report here and here being able to exploit the weakness to remotely log into a Mac try, with no previous local login attempts.
This post was updated extensively over several hours as new details became available.