High Sierra Bug Allows Root Access With Blank Password

chethan177, in the Apple Developer Forums, two weeks ago (via Mike Myers):

If you’re unable to login at startup using username: root and empty password, then login with your existing account (standard user).

Again, head over to System Preferences>Users & Groups. Click on the Lock Icon. When prompted for username and password, type username: root and leave the password empty. Press enter. This might throw an error, but try again immediately with the same username: root and empty password. This should unlock the Lock Icon.

@jeremydmiller78, a week ago, posted a video.

Lemi Orhan Ergin, yesterday (Hacker News):

Dear @AppleSupport, we noticed a *HUGE* security issue at MacOS High Sierra. Anyone can login as “root” with empty password after clicking on login button several times. Are you aware of it @Apple?

Juli Clover:

There appears to be a serious bug in macOS High Sierra that enables the root superuser on a Mac with a blank password and no security check.

Adam C. Engst:

Wait, it gets worse. I’ve confirmed that if you have Screen Sharing (or Remote Management) enabled in System Preferences > Sharing, someone can connect to your Mac over the local network or, depending on your Internet setup, the outside world. I did this from a guest account on my MacBook Air and ended up at a login window on my iMac, from which I was able to click the Other button, enter root and no password in the appropriate fields, and create a root user account on my iMac.

The practical upshot is that anyone who has local or network access to your Mac can log in and access all files with impunity.

Rene Ritchie:

“We are working on a software update to address this issue,” an Apple spokesperson told iMore. “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. 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.”

Juli Clover:

Disabling the root user account again follows the same steps, but at the “Edit” portion of the process, you’ll select “Disable Root User” to remove the option. Until the bug is fixed, though, you’ll want to leave the root user account intact to prevent it from being accessed without a password.

Ilja A. Iwas:

Not impressed by Apple’s poor handling of yesterday’s 0-day. No e-mail, no mention on http://support.apple.com, only a KB-link circulated in the media that doesn’t even acknowledge the issue.

John Gruber:

I rarely describe any bug as inexcusable, but this is inexcusable.

Peter Maurer:

Oh how I’d love to know how they ended up with code that creates root as a side effect. “Account doesn’t exist” => “let’s create it” seems like a weird train of thought. For testing, perhaps?

Rui Carmo:

The scheduled release approach (whereby software is shipped in lockstep with increasingly predictable hardware launches) has been steadily eroding quality across the board (and iOS 11.0 was a great example of that), but macOS seems to be falling into full-fledged neglect, and as a primarily UNIX user, I’m flabbergasted this kind of thing is even possible in 2017.

Nick Heer:

I’m not deluded enough to think that complex software can ever be entirely bug-free, but I’d love to see more emphasis put on getting Apple’s updates refined next year, rather than necessarily getting them released by mid-September.

[…]

For extra irony, recall that High Sierra was pitched as a refinement of MacOS Sierra.

Previously: Encrypted APFS Volume’s Password Exposed as Hint.

Update (2017-11-29): Patrick Wardle:

Starting with the odm_RecordVerifyPassword function, it invokes an unnamed method, ‘sub_826b’. This subroutine first invokes another helper function, ‘sub_826b’, to “read shadowhash data from” from the account that the user (or attacker) is trying to log in to. For enabled accounts (such as the user account) this read will succeed as this data exists.

[…]

For disabled accounts, (such as root account that is being targeted), this information is not present, so this function will fail!

[…]

Since a non-zero value was returned, execution continues with a call to various methods such as sub_13d00. As the debug log statments in the decompilation show, these will perform an upgrade from a crypt password to a shadowhash or securetoken[…]

[…]

However, if we look at what these ‘upgrade’ subroutines are called with, it’s with the password we provided[…]

Apple has fixed the bug:

A logic error existed in the validation of credentials. This was addressed with improved credential validation.

Rene Ritchie:

Apple sent me the following statement:

When our security engineers became aware of the issue Tuesday afternoon, we immediately began working on an update that closes the security hole. This morning, as of 8:00 a.m., the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra.

We greatly regret this error and we apologize to all Mac users, both for releasing with this vulnerability and for the concern it has caused. Our customers deserve better. We are auditing our development processes to help prevent this from happening again.

Patrick Wardle:

Apple’s patch for #iamroot bug “improves cred validation” ... meaning they perform extra checking on the call to od_verify_crypt_password() In prev. blog posting we surmised “it should fail” - it did; appears they just didn’t check💥😅 👋🏽

Unfortunately, the update breaks file sharing.

Apple:

If you experience issues with authenticating or connecting to file shares on your Mac after you install Security Update 2017-001 for macOS High Sierra 10.13.1, follow these steps to repair file sharing[…]

John Gruber:

It’s natural to speculate how a bug as egregious as the now-fixed High Sierra root login bug could escape notice for so long. It seems to have been there ever since High Sierra 10.3.0 shipped on September 25, and may have existed in the betas through the summer.

Steve Troughton-Smith:

Bad actors could have known about this since June and we’d never know, as [remote] root access to a machine would let you easily cover your tracks.

Update (2017-11-30): Jeff Johnson shows that Apple is now distributing a new version of the update, which doesn’t break file sharing. The changes seem to indicate that the file sharing problem was caused by a flaw in the updater itself, rather than in the code that was patched to fix the root issue.

Update (2017-12-01): Andy Greenberg (via Hacker News):

Those who had not yet upgraded their operating system from the original version of High Sierra, 10.13.0, to the most recent version, 10.13.1, but had downloaded the patch, say the “root” bug reappears when they install the most recent macOS system update. And worse, two of those Mac users say they’ve also tried re-installing Apple’s security patch after that upgrade, only to find that the “root” problem still persists until they reboot their computer, with no warning that a reboot is necessary.

Update (2017-12-05): Jeff Johnson:

AFAICT you don’t get the so-called “automatic” security update 2017-001 as long as you have all the prefs off?

Howard Oakley:

These are indicators that Apple is in the process of rewriting a lot of macOS. In the case of the root user vulnerability, this was in Open Directory, whose source code may well date back ten years or more. It has been my contention that macOS-only code, such as Time Machine, gets considerably less resources than that which is shared with iOS, but that doesn’t explain why, if such macOS development is being poorly resourced, Apple’s precious engineers are busy rewriting systems such as Open Directory, when there are so many other demands.

Thomas Reed:

Since the update doesn’t require a restart, and since many Mac users can be rather averse to restarting, this means that people upgrading from 10.13.0 to 10.13.1 could easily end up being vulnerable to this bug for weeks or months, until they next decide to restart. Keep in mind that nearly all 10.13.0 users have probably already had Security Update 2017-001 installed automatically at this point, putting them into a pipeline heading straight for this issue.

Update (2017-12-11): Accidental Tech Podcast says that the bug was actually reported to Apple via the proper channels around the same time as chethan177’s forum post.

Apple Software Quality Bug Mac macOS 10.13 High Sierra Passwords Screen Sharing Security

14 Comments RSS · Twitter

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ