Slashdot Mirror
MacOS High Sierra Bug Allows Login As Root With No Password (theregister.co.uk)
An anonymous reader quotes a report from The Register: A trivial-to-exploit flaw in macOS High Sierra, aka macOS 10.13, allows users to gain admin rights, or log in as root, without a password. The security bug is triggered via the authentication dialog box in Apple's operating system, which prompts you for an administrator's username and password when you need to do stuff like configure privacy and network settings. If you type in "root" as the username, leave the password box blank, hit "enter" and then click on unlock a few times, the prompt disappears and, congrats, you now have admin rights. You can do this from the user login screen. The vulnerability effectively allows someone with physical access to the machine to log in, cause extra mischief, install malware, and so on. You should not leave your vulnerable Mac unattended until you can fix the problem. And while obviously this situation is not the end of the world -- it's certainly far from a remote hole or a disk decryption technique -- it's just really, really sad to see megabucks Apple drop the ball like this. Developer Lemi Orhan Ergan was the first to alert the world to the flaw. The Register notes: "If you have a root account enabled and a password for it set, the black password trick will not work. So, keep the account enabled and set a root password right now..."
By default, there's no root account. Attempting to log in as root with no password multiple times creates a root account with no password.
https://forums.developer.apple.com/thread/79235
'course, this post may not have been reported directly to security folks. it was something that they should have found while monitoring the beta forums, though.
I just reproduced it.
I have a MacBook Pro that I upgraded to High Sierra (10.13.1) over Thanksgiving. My login screen is set to only offer the pre-defined user accounts. I logged into a non-privileged account that I keep around for testing purposes. Went to the top-level of the file system; did a "Get Info" on a folder I didn't have access to; asked it to show me "Sharing and Permissions"; clicked the lock icon to unlock them; got a username/password dialog box; entered "root" as the username with a blank password once; the dialog box shook and cleared; entered "root" with a blank password again, and the action completed with the lock unlocked. Now when I go to the login screen, I have an "Other" account showing; if I click "Other" I get a username and password dialog box; if I enter "root" as the username with a blank password Bob's your uncle. Logs right in, shows the username in the upper left of the screen as "System Administrator." The account has root access to the machine.
This is probably exercisable remotely if remote logins are enabled (screen sharing, anyway); I don't think anything I did would not be doable through a remote login (but I have not the means to test at the moment). Seems like there might be some blood on the floor over this one, at least at some organizations. I don't envy sys admins in large academic environments either.
I followed up with a remote test, and the attack works fine over "Screen Sharing" (VNC) to my iMac 27" from circa 2013 that I also just upgraded to High Sierra (10.13.1) over Thanksgiving. Merry Christmas.
Needless to say, I now have a root password set on my Mac-in-trashes. I didn't before because the root account isn't normally enabled and I was not being sufficiently paranoid; sigh.
So, I just tried it on a completely fresh install, and I was able to reproduce the bug. No idea why it didn't manifest on any of my existing installations.
I would expect that the relevant teams at Apple will push an update to fix this in a day or two at the most. In the meantime, you can work around this from any administrator account by setting a password on the root account ( open a terminal window, enter "sudo passwd root", and follow the prompts.)
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
No, by default the root account is disabled, but it's there.
This smells like a misconfigured PAM. Apple does a lot of weird and non-standard stuff with the *nix user land, so they probably introduced the vulnerability that way. An improperly configured PAM stack can, for example, try a particular auth mechanism a preconfigured number of times before moving to the next auth mechanism. That fallback mechanism could be the Apple directory service, which doesn't handle the root user and leaves it to the system, but ignores the *nix convention that a passwordless entry in /etc/passwd is a disabled account. Not sure exactly what is happening and don't have a system to test on.
Best workaround is to set the shell of the root user to /bin/false. That will block any attempt to get an interactive login.
This is incorrect. LOGGING IN AS ROOT is disabled. You can still trivially get to be root from a user account in terminal by typing "sudo su" and pressing enter then entering the USER password when prompted. To verify, once you do this, (and have a "#" prompt,) type "whoami" and see if it doesn't respond, "root". To fix this, while logged in as root, just type "passwd" and set the super-user (root account) password. Make sure you will be able to remember it, as if you ever DID want to do anything AS root, you might need that. (You could change it, forget, and still be able to access root through the same means, using "sudo su," as it will still only ask for the USER password to get there, but if you ever did alter... /etc/... something, I forget what, to make it possible to log in AS root, properly, (rather than backwards through sudo su,) which I believe IS possible though can't recall how exactly, you WILL need the root password you just set to log in as root.).
BEAR IN MIND: you can also, once a root password is set, type "su root" and become root THAT way. Going THAT route, you WILL be prompted for the ROOT password, NOT THE USER one. (It won't tell you which it wants, it's just that going 'sudo su' and typing the root password fails, typing the user password succeeds, while going 'su root,' typing the user password fails, but the root password (once one exists,) succeeds.). I don't know if you can "su root" with no root password set, in fact, I think it's designed NOT to let you do that, since by HAVING no root password, there'd be no way to log in. "/bin/sh" would check for the /etc/passwords file, or whatever, wherever it's kept on a Mac..., and finding no entry for root, would fail the login attempt, and reply "su: Sorry" or something like that. (I can't now test how that works on a Mac, having recently added a root password to my machine, but I vaguely recall it went something like that.)
Or something like all that. It's late enough that I could be a little fuzzy on the details. I think actually that once "su root" works, that just using "su" would work too, as it defaults to root...
Our reign has gone on long enough. Indeed. Summon the meteors.