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.
You're missing that it works if there is a disabled root account without a password too. Many people just give their own account admin access or create an admin account that isn't named root and disable the "root" account. You'd think that would be safe. It isn't.
is "courage" to go beyond the heteronormative system of power and privileges. Why would you require privileges in a progressist society where everybody is equal.
USER LIVES MATTERS !
Yes this is obviously the fault of Tim Cook. Forcing the poor programmers to insert security holes is indeed his MO as should be obvious from this article:
http://www.theregister.co.uk/2...
I can understand if it let you in after hitting enter once, because then it's just ignoring something. If it denies entry the first few times and then lets you in, what do the *nix gurus think is happening after the first few denials to have it change its 'mind?
"There is no real right or wrong, just what the majority accepts at the time."
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.
So, logging as root without password works on High Sierra if there's a root account without password?
Just works with whatever is the default user configuration. I never modified anything other than creating an OSX user for myself.
What's even better is that if you have remote desktop turned on, anyone can connect and login as root.
Yes this is obviously the fault of Tim Cook. Forcing the poor programmers to insert security holes is indeed his MO as should be obvious from this article: http://www.theregister.co.uk/2...
Or maybe under Tim Cooks leadership the overall quality of Apples software and hardware has noticeably declined.
One can have anything if one has Courage.
Just because you are paranoid does not mean that no-one is out to get you.
Parent is also incorrect, there is always a root account. I would hazard a guess the issue is with sudo as that is the underlying mechanism for privilege escalation.
Is no root password a requirement for this "bug"? My Macbook has a root password. I followed the directions in the summary, and it did NOT give me root. I tried several variations. Nothing worked. So as far as I can see there is no bug.
This is literally nothing like that issue. To "exploit" that issue you already have to have root access. It is the typical "OMFG, if you are root you can get root privs!" cry of the moron without a clue.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Seriously, any one who knows a bit about unix will enable the root account and set a fairly strong password.
It is only the "Its Apple! Its immune to hacks!! Its got the ultimate security!!!" fanbois will be affected.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I've tried to reproduce it on three different machines, all on the latest beta, and it's not happening for me. From what I've seen, it doesn't appear to be remotely exploitable, so it's only an issue if an attacker has physical access to your machine.
So, I'd say it's serious but not catastrophic.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Apple says you're wrong. Their Magic keyboard with numeric keypad has a return and enter key.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
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.
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.
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."
Nothing "Just Works".
My car requires maintenance from time to time. So does my fridge. And my Synology (which seems to have a PSU issue at the moment). QAnd my cellphone. My computer (MacBook Air) needs periodic maintenance too....
Having said that, I've used pretty much everything there is to use on the desktop during my life:
MS-DOS 1.1
Commodore 64.
CP/M.
Apple ][
MS-DOS 3.2 - 6.2
Windows 3.1 to 98se
FreeBSD
Linux (Slackware - RedHat 6)
NT4-Windows 10
OSX Since 2009.
And I have to say that, in the desktop, the thing that bugs me the less and requires less periodic maintenance, is MacOS (formerly OSX) by a huuuuuuge margin.
At work is a different thing, there I had to sysadmin things like:
HP-UX, Solaris, VMS, WinNT4, RHEL, even Sinix for crying out loud!
But now is Linux all the way, either REHL or Suse. All require periodic maintenance (after all, all are enterprise systems) and all behave more or less well.
*** Suerte a todos y Feliz dia!
From the GUI go to Command-Space > Directory Utility, click the lock and check the Edit menu for "Enable Root User" or "Disable Root User" options.
From a Terminal use the dsenableroot command.
Doesn't work on mine (have 10.13.1)
Having an enabled root account with a non-blank password disables this vulnerability. Does that match your situation?
They are not an enterprise company.
and they will tell you this, ad nauseam...any time you have an issue they cant fix.
People running OSes that come with the root account disabled. Having the root account disabled is being used as a security feature. Ubuntu follows the similar practice of disabling the root account by default, and there is no password set there either. You can of course enable it if you want but most people don't, as disabling the root account and limiting superuser actions to sudo isn't a bad idea at all. The fact that in 10.13 you're able to re-enable the root account by trying to use it with a blank password a few times is pretty upsetting and really has nothing to do with the practice of disabling root at all.
If you enabled the root account and set a password, like you did, there is no problem. However, if you never set up the root account (like the vast majority of users), the dialog first rejects but then accepts the login after a few attempts. That's definitely a bug, and a very serious one because many people just put their laptop to sleep instead of shutting it down, which makes the login box the only remaining protection even if you have disk encryption enabled. Any thief can now open the lid, log in as root, and read your files.
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.
Wow... they'll give anything a "5: Informative" won't they?
Yes, you're missing something. There IS a root account, it's just configured not to let you log into it. If you'd like to see, open a terminal on a Mac, type "sudo su" followed when prompted by your user password, then type the command, "whoami" and press enter. It'll respond "root". This is true for all Macs, as far as I know, at least, as they come from Apple. Maybe there's a way to change the root account, so you can make this be, not true, as it were, for YOUR specific Mac... but yeah. When you're done marveling at how you have a "#" prompt now, (indicating super-user access, as opposed to the normal unprivileged "$" prompt, you might want to type "exit" and get out of super-user mode, before you go and rm -rf something important.
Our reign has gone on long enough. Indeed. Summon the meteors.
I wonder if it works when logged in via the guest account (if enabled)?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
It's pretty common to do on BSD systems, because there are a bunch of things that add extra checks for blank passwords and so effectively disable use of the root account. For example, SSH won't allow root login if the root password is blank. Only members of the wheel group can su to root and if you put users in a sudo-enabled group but not in wheel then no one can su to root. If you can mark consoles as insecure then root login is disabled by default on them. This basically leaves you with booting to single user mode as the only way of logging in as root. This is basically the setup that macOS uses: the root account is effectively disabled by setting the password to blank (modulo bugs like this).
I am TheRaven on Soylent News
I propose we give this bug a name: Superuser Login Absent Password, or SLAP for short.
A root account with no password is a fantastic idea to increase user friendliness. Everything should be easy to use. Remember the UI principles. Point and click rather than Remember and Type. Why should a Mac user have to be burdened with remembering a password?
I'll see your senator, and I'll raise you two judges.
The fix was just posted.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."