A newly-discovered flaw in macOS High Sierra — Apple’s latest iteration of its operating system — allows anyone with local (and, apparently in some cases, remote) access to the machine to log in as the all-powerful “root” user without supplying a password. Fortunately, there is a simple fix for this until Apple patches this inexplicable bug: Change the root account’s password now.
Update, Nov. 29, 11:40 a.m. ET: Apple has released a patch for this flaw. More information on the fix is here. The update is available via the App Store app on your Mac. Click Updates in the App Store toolbar, then use the Update buttons to download and install any updates listed.
Original story:
For better or worse, this glaring vulnerability was first disclosed today on Twitter by Turkish software developer Lemi Orhan Ergin, who unleashed his findings onto the Internet with a tweet to @AppleSupport:
“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?”
High Sierra users should be able to replicate the exploit by accessing System Preferences, then Users & Groups, and then click the lock to make changes. Type “root” with no password, and simply try that several times until the system relents and lets you in.
How does one change the root password? It’s simple enough. Open up a Terminal (in the Spotlight search box just type “terminal”) and type “sudo passwd root”.
Many people responding to that tweet said they were relieved to learn that this extremely serious oversight by Apple does not appear to be exploitable remotely. However, sources who have tested the bug say it can be exploited remotely if a High Sierra user a) has not changed the root password yet and b) has enabled “screen sharing” on their Mac.
Likewise, multiple sources have now confirmed that disabling the root account does not fix the problem because the exploit actually causes the account to be re-enabled.
There may be other ways that this vulnerability can be exploited: I’ll update this post as more information becomes available. But for now, if you’re using macOS High Sierra, take a moment to change the root password now, please.
Successfully tested SSH remote root access via this bug. Also only seems to be part of the upgrade path to High Sierra. Clean installs of HS do not seem to encounter this issue.
I have a clean install of High Sierra and it still has the vulnerability.
Confirmed, have multiple fresh installs of 10.13.X and multiple upgrades from 10.12.X -> 10.13.X and *all* exhibit this exploit behavior.
sshd has PermitEmptyPasswords set to false by default
This is exploitable via SSH tunneling? Ouch.
Also, a CERT analyst has noted that Apple Screen Sharing and Remote Management can give access to attackers using this vulnerability. That really stinks. Source:
https://twitter.com/wdormann/status/935626466481639428
https://twitter.com/wdormann/status/935630148229107713
Upon reading, I’m hoping that sshd_config files in Mac OS should be defaulting to #PermitRootLogin prohibit-password configuration. It does appear to do so in Ubuntu (https://ubuntuforums.org/showthread.php?t=2359172), but Mac OS? I don’t know. I’m reading that back in 10.9, this was set to “Yes” for some reason, but how about later versions? I can’t test this myself, since I don’t have access to a Mac.
This is a point that deserves testing. I need to go find someone to test this exact thing.
If the default does indeed set that at “prohibit-password”, then there shouldn’t be any concern (crosses fingers, hopes for the best) because that part of the config would – well, at least should – block the connection from the start before anything else gets invoked. If not, though, well… there may indeed be a problem here. Again, this deserves to be tested.
Digression: If anyone’s wondering why that setting goes beyond simple Yes/No configurations: The point of that appears to be to allow root login through SSH but make you configure key authentication instead of password. And I’ll end this here because it’s really starting to veer off topic.
Brand New Mac, opened out of box yesterday, just tested bug, Yep its there!
sshd has empty passwords as well as root login disabled by default on High Sierra. Does this bug bypass these settings?
Oops,that’s rather a large clanger dropped by Apple..
And they still boast about their security ?
Big problem “boast” vs “fact.” People will listen to boasts in preference to facts.
https://support.apple.com/en-us/HT204012
Better instructions on how to set a password. But be cautious – having one set has caused strange issues historically with some applications, and the only fix was to reinstall the OS. Not sure if that’s still true.
It appears that an alternate workaround is to power off (not just suspend) the machine. The initial FV2 password prompt doesn’t appear to be vulnerable.
Update – cold-off appears secure. Still at risk from remote access, screen sharing, physical access when booted. Malware risk unknown
This is ridiculous.
Merciful bots…thank you so much for putting this out there. You might point out that when typing passwords into the terminal box (via spotlight search) ~ the letters you type are INVISIBLE. Type carefully. The password they are asking for there is the one you use to unlock your computer ~ NOT your email password, NOT your Apple password – the one you use to unlock your computer to begin using it.
Then, type in your new root password and type it again to confirm it (again, the typing is INVISIBLE.
That’s the sort of stuff that throws us old people off for a minute, but I got it done! Thanks again!!
In chatting with knowledgeable people in an Apple internal forum, you are correct that you should change the root password, but do not disable root access. If it is disabled the bug will re-enable it.
We are currently testing this and it appears that if you disable the root account using the directory utility, then the vulnerability is there.
However if you use the dsenableroot -d command, for root then the account cannot then be exploited. Not sure if it disables it in a different way that the directory utility?
Can anyone else please test this and report back?
This was using a machine that had been upgraded to High Sierra fwiw.
Apple also F-ed up with the iOS update as it seems you can now activate a mobile hotspsot from your computer even if the phone disallows it.
That’s misleading. An Apple device that shares an iCloud ID with the phone can activate the mobile hotspot and use it. But iCloud IDs are personal, and should not be shared. So yes, I can use my iPhone’s hotspot from my computer. But no one else can. This isn’t new; it’s been a feature for several iOS versions.
Saw a screenshot suggesting that this isn’t a bug and that Apple knew about it. I posted it in the comments on your facebook post about this. If it’s true Apple knew about this and used it as a “fix” for login issues that makes it even worse.
That seems very unlikely, almost in the tin foil hat category.
https://imgur.com/gallery/t8O1S
That appears to be a random person posting on an Apple forum, not official advice from Apple. Which does suggest that this phenomenon was already known in the wild, but apparently no one recognized its significance! (no one who was willing to report it, anyway).
True, it doesn’t necessarily mean an Apple tech suggested this, but you’d think with people suggesting this as a work around for what appears to be a permission or logon issue, that Apple would catch wind of it. Problem is, we don’t know just how long people have known about this.
Does anybody NOT have filevault turned on?
I can confirm that the bug exist when file vault is enabled, and a fresh High sierra installation downloaded from the Apple server.
Something’s bugging me. Even though it’s inexcusable from Apple, why shout like a dork about a security issue instead of quietly tipping Apple about it? On Twitter, of all places.
So everybody knows about it as fast as possible maybe?
Rumor from the tin foil hat category has it, that Apple silently relented to all the requests of NSA to grant access to locked devices that way.
Apple is notoriously horrible at a) admitting that bugs exist and b) actually fixing them. I don’t blame that guy at all for tweeting it. I am still waiting for Facetime bugs to be fixed, and it’s been out for years. Apple has gotten absolutely horrible at quality control, and I’m glad they got called out finally for a huge, huge mishap.
MacOS 10.13.1, updated mac mini from 2011, and it did not work for me.
Tried to unlock User and groups ( ~ 10x), tries ssh root@… nope.
The fix is beyond my technical comprehension. (What is this Terminal?) I’ll keep my computer close and wait for the next OSX update.
Found: I thought its the locale, but it is just an (unrelated) change in PW just after the last update.
Windows has always been the most vulnerable operating system due to its large user base, hence making it the primary target of hackers. With more and more people buying Macs security holes in the Mac are getting more attention.
Karl, just use spotlight and type in terminal until you see the app. You can also change the root password without terminal; just google ‘how to change root password mac’ and follow the simple directions.
Karl, spotlight is the search function built into the operating system. You can access it by clicking the little magnifying glass icon in the upper right corner of your screen, or by pressing the “command” key and the space bar at the same time. When the spotlight search box pops up, type “terminal” without the quotes and it should launch it. Then type “sudo passwd root”. When you type your password, nothing will show up. Just make sure you type slowly and carefully, and that you remember or otherwise somehow record the new root password. After typing your password, hit the “enter/return” key and you should be all set.
I am seeing a lot of FUD about what appears to be a mistake in packaging a testing configuration setting as the default for the production release. Good job on announcing the bug with an effective mitigation strategy Brian.
Apple has released a patch–it is available now.
Here’s the announcement – https://support.apple.com/en-us/HT208315
Here is his account: Apple knew since 13 Nov 17, did nothing.
https://medium.com/@lemiorhan/the-story-behind-anyone-can-login-as-root-tweet-33731b5ded71
A week ago the infrastructure staff at the company I work for stumbled on the issue while trying to help one of my colleagues recover access to his local admin account. The staff noticed the issue and used the flaw to recover my colleague’s account. On Nov 23, the staff members informed Apple about it. They also searched online and saw the issue mentioned in a few places already, even in Apple Developer Forum from Nov 13. It seemed like the issue had been revealed, but Apple had not noticed yet.
Yesterday the infrastructure staff informed me that they had to set-up a root password on my Mac so that it won’t have the issue. I saw the issue with my own eyes and thought that it was unbelievable!
Then I decided to inform Apple via Twitter. The issue was very serious. It has already been mentioned in forums and revealed publicly few weeks ago. I thought I had to ask Apple “are you aware of it?”.
Apple’s response:
https://www.reuters.com/article/us-apple-cyber/apple-to-review-software-practices-after-patching-serious-mac-bug-idUSKBN1DT2TJ
I have to wonder how such simple mistakes creep into this OS? Remember the GoTo bug that defeated all SSL cert checking in the browser?
Are these deliberate hidden entry points by design? Or someone nefarious sneaking into Apples code base at night and inserting them??
Because these coding mistakes are just too dumb to be genuine.
The modern OS – from apple, microsoft etc. is indeed secure. And has been made so by the best programmers in the world, ever… So they keep on telling us. The trouble is the word ‘secure’, what does it mean?, and secure for whom? There is the question. For whom do’th modern security make secure? Not the common man, surely. Have you ever seen any of the 1% conservative ‘elite’, affected in any way, ever? Timmy, Billy, Rupert? Every single element in every single aspect of modern computing and communications is compromised. Right from PHY to APP – all layers of the cake are ‘modified’. As is ‘security’ for all those who are not ‘secure’ by definition… So the truth revealed here is an ancient one – it’s just class warfare, again. And class warfare facilitated by those who have surfed the bow wave of the powerful since the powerful became powerful… So why isn’t there an open hardware/software revolution that enables ‘security’ for the masses, created by open engineers and scientists? Because it is actively subverted by the ‘secure’…
There seems to be a major, fundamental difference between a for-profit company’s OS (windows/mac) and a non-profit, such as Linux.
I’ve seen a few comments on developer forums that Apple’s fix for this breaks MacOS file sharing. As I haven’t installed High Sierra I can’t test it myself, but it’s been reported by people I generally trust.
And now there’s a fix for the fix: https://support.apple.com/en-us/HT208317 to repair the file sharing issue.
Thanks for the update on newly-discovered flaw in macOS High Sierra
Brian, thank you for the update! I installed it and the update screen says it was successful! I am sure your reporting had a great deal to do with it being released to us shortly after your report! We sure appreciate your time/effort!
For years, I’ve had to go into all my client’s computers and set a password for what was called the “hidden administrator” in Windows. It is the same thing as ‘root’. I would then disable it by command line, or with the MMC if they had one.
I discovered the fact that malware made a bee line for this account a long time ago when W2K came out, and it didn’t take long before my honeypot got popped, and this account was taken over. For anything Windows 7, I still do this – I don’t have any idea if Window 10 disables a similar account or not – I’m not even up to snuff on everything Win 8, 8.1, 10 yet anyway. I still get malware occasionally, that tries to enable this account and log in; but no cigar of course.
The built-in Windows administrator account has been disabled (by default) in every version of Windows since Vista.
Installed Apple’s emergency update last night.
Here’s what the tell you to enter in terminal to make sure fix was delivered and completed…
“what /usr/libexec/opendirectoryd” enter in terminal
“If Security Update 2017-001 was installed successfully, you will see one of these project version numbers:
opendirectoryd-483.1.5 on macOS High Sierra 10.13
opendirectoryd-483.20.7 on macOS High Sierra 10.13.1”
Yeah great, now do you have any idea what your new root password is?
Did apple tell you your new root password?
Hah! Good question!
It’s a very interesting flaw.
It’s a good example of how hard it can be to write authentication software and how a subtle bug can have
dramatic consequences. These kinds of problems are a class of their own and they can be very difficult to spot.
First, assigning a password to an account should not more secure than disabling password
authentication for it. In Unix, historically, it has been achieved by storing an impossible encrypted
password such as an asterisk. Remember that the Unix password encryption routine always generates
a fixed length output and the encrypted password usually included a “salt” intended to choose a variant
of the algorithm/one way encryption key.
Still, back in 1991 I saw by chance an example roughly similar to this one. It affected a software package called
Atlantix Axcess, which was a Lan Manager server for SCO Unix. Its login process was flawed and
it allowed to login to any “asterisk locked” account such as “bin”, “daemon”, “tcb”… So it was pretty
trivial to get root access. Just think that the system files were owned by “bin”.
How could that possibly happen? Well, maybe a function with an uninitialized variable returned TRUE
when it failed to extract a “salt” (which at the time was two characters) from a single character (the infamous
asterisk). Remember that back in the early 90’s compilers weren’t so clever.
A friend pointed out another different to spot flaw in systemd, for example. When a service was configured to
run as a user whose name begun with a number, systemd interpreted it as a numeric uid. The discussion on
Github showed an example with “0day” user name which indeed was interpreted as “0”.
Systemd tried first to evaluate it as a number. It succeeded, so it was interpreted as the “0” user. They could
have changed the evaluation order, first doing a user name lookup and, if failed, trying to evaluate the number.
Still, the situation would have been interesting if a user was removed from the system while forgetting to
remove some systemd configuration. Suddenly those commands would be executed with root privileges.
In this case (Apple) it not only affected the root account, but, as far as I know, any locked account. Which is
certainly awful, because some services such as sshd tend to consider the uid 0 as special, but not
others such as daemon, _uucp (hey it’s still here despite telnet being removed!), etc.
UPDATE: MacOS High Sierra Update Reintroduces “Root” Bug
Source: https://www.wired.com/story/macos-update-undoes-apple-root-bug-patch/