MacOS High Sierra Bug Allows Login As Root With No Password (theregister.co.uk) 237
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..."
All it requires... (Score:3, Funny)
USER LIVES MATTERS !
Re: (Score:2)
So you're saying this is revolutionary?
Re: (Score:2)
fwiw, the OS X spell-check was at some point the only major OS-native spell-check which recognized "misandry" as a word. (yeah, i know it's a joke, i just thought it was interesting.)
Work-around (Score:2)
Set the root password to something long and hard to guess (32 chars of mixed-case alphanumeric should do). Do this by running as an administrator:
sudo passwd -u root
This should do until Apple releases a real fix.
Source [twitter.com]
Re: (Score:2)
...but make sure you write down that 32 character password since you won't be able to sudo without it!
Just curious what this will break...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why/how though? (Score:5, Interesting)
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?
Tests made sure it works. Garbage in, garbage out (Score:2)
My educated guess from 20 years in computer security:
The graphical UI it gives up after a few tries, which is reasonable. Unit tests tested that you can login that way and maybe tested that it gives up.
Separately, on the underlying Unix side they may have tested that part well - if you enter a correct password you get in, an incorrect password doesn't get you in.
In Integration testing UI designers made sure it WORKS - you can log in that way. They didn't test crazy shit like entering a million-character pas
Re: (Score:2)
My guess would be a flaw in the logic that handles several failures in a row. Maybe they tried to put some rate limiting in or something like that, but accidentally proceeded with logging in at that account instead.
That would be somewhat similar to their GOTO FAIL bug from a while back. I really hope we get the full story because if it's the same thing again it strongly points to interference.
Re: (Score:3)
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?
From my understanding, the first time it denies you access because there is no root account on the box. Once it fails to log you in, the OS is actually creating the root user. The second time it lets you log in with that user, which has no password. I've seen people say that if you do it on the login screen it immediately creates the account and lets you in without the failed password attempt.
User chethan177 was actually first to report (Score:5, Informative)
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.
Re: (Score:3)
This is very funny, he actually found the biggest user escalation exploit in recent memory and he just nonchalantly posts it as an answer to a thread about someone who had his admin accounts turned to standard, with his only comment being "Solution 2 worked for me. No idea how or why. Hope this helps.".
Unless he did not stumble upon it, but read it elsewhere and that is why he is so "business as usual"...
Re: (Score:2)
Hey, It Just Works.
Re: (Score:2)
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.
This is something that should have been found before even going to beta.
I mean we don't even expect this kind of dimwittery from Microsoft any more.
Mac... its more secure than PC (unless you try to test it).
Thanks for stealing my submission (Score:2)
Re: (Score:2)
Re: (Score:2)
If the black password does not work ... (Score:3)
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.
Re: (Score:2)
It is only the "Its Apple! Its immune to hacks!! Its got the ultimate security!!!" fanbois will be affected.
Careful, I recently got into a week long flamewar with phayes by mentioning that such people exist. You don't want to trigger that raving lunitic, trust me.
...except it also works remotely for FileVault (Score:2)
so it's not exactly "far from a remote hole or a disk decryption technique" as the post suggests. If Screen Sharing is turned on, it allows remote login; if you have access physically or via Screen Sharing, you can use it to turn off FileVault. So it's potentially both a remote hole AND a disk decryption technique. "sudo passwd -u root" now if you hadn't already reset the root passsword!
Who among the slashdot readers...? (Score:2)
did not enable root and set a hard to guess password?
I mean, come on, a lawyer, designer, doctor, writter or grandma with a mac, I can understand that is actually BETTER for them to have no root account by default. No disrespect, maybe you Lawyer/designer/writter/doctor/gramma are ultra smart in your field (and perhaps many more). And I am sure know you know way more about your field than I'll ever be....
But Slashdot has a big proportion of programmers, computer scientists, and EETREs (Electrical/Electronic
Re: (Score:3)
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 thin
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It seems as if it's a logic bug when upgrading the password store. The store is upgraded with the password entered. I think the reasoning behind the code may have stemmed from the fact that to upgrade a password hash to a more secure hash, you wait for the user to enter their password so that you can hash it with the new hash function... but that's not a reason to enable accounts that are disabled, or to update the hash if the provided one doesn't match. See https://objective-see.com/blog... [objective-see.com]
Dumb Question.. (Score:2)
Who doesn't set a root password on a new computer?
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
The majority of Mac users.
That puts me in the minority. I chose to get a Mac because it's unixy under the hood and has nice hardware. So I can bring up a bash shell and run GCC and grep and awk all day long. So as with my Linux boxes, as soon as I got it, the first thing I did was set the root password.
Perfect name for this bug: SLAP (Score:4, Interesting)
I propose we give this bug a name: Superuser Login Absent Password, or SLAP for short.
Re: (Score:2)
Re:Am i missing something here? (Score:4, Informative)
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.
Re: (Score:2)
That makes sense, thanks. Both the story and the linked article weren't really clear.
Re: (Score:3, Interesting)
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.
Missing software freedom (Score:2, Interesting)
From what I gather so far, you're missing software freedom. Whether this is creation of an unprivileged account named "root" or granting admin privileges to anyone patient enough to "click on unlock a few times" (as the story intro claims), something is wrong. Are MacOS users still being denied the permission to inspect what's really going on in the source code, fix the problem, and distribute fixed code to others?
In the referenced twitter.com thread, Apple wants to "take a closer look at what's happening t
Re:Am i missing something here? (Score:4, Interesting)
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.
Re: (Score:2, Informative)
Re: (Score:2)
you're correct about the behavior of su; i tested it last night after hearing about this.
Re: (Score:2)
Why so complicated :D
Just do "sudo bash"
But well, obviously I simply do a "su -"
Re: (Score:2)
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.
Yes, you are correct. What I meant was any login (invoking the standard pam_unix module) to the root account is disabled, which includes "su root". Sudo works because it uses the setuid bit to elevate your permissions without first authenticating the root account. It is a convenient method to allow people to run programs as root without logging in as root, and linux distributions such as Ubuntu have been setting up the userland that way by default for many years. It works pretty well as long as you have a p
Re: (Score:2)
A disabled account in unix has as password a * (but it still allows SSH login, provided the keys are distributed)
Having an empty password field is completely allowed.
Re: (Score:2)
SCP won't work if the default shell is set to /bin/false, and current versions of sshd don't allow root logons by default unless you install an ssh key. Although giving the root account an invalid shell will also break single user mode and various system functions, possibly even preventing the system from booting.
Re: (Score:2)
Although giving the root account an invalid shell will also break single user mode and various system functions, possibly even preventing the system from booting.
Are you sure about that? I admit I haven't tried it, but I don't see why it wouldn't work. The only reason to consult /etc/passwd would be to authenticate the root account, which pam_unix treats as disabled if the password is blank. Su and login require a valid shell entry, but AFAIK nothing else does. Sudo doesn't require the root user to have a shell, and neither does init. So it seems like pretty good insurance to me. If, for example, somebody sets nullok in pam.conf allowing the root user to login with
Re: (Score:2)
current versions of sshd don't allow root logons by default unless you install an ssh key.
Bullshit. That is a configurable option in /etc/ssh/sshd.conf
PermitRootLogin yes
or
PermitRootLogin without-password
Re: (Score:2)
Re: (Score:3)
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?
Re: (Score:2)
Re: (Score:2)
By default, there's no root account.
Are you sure of that? [apple.com]
The root user is disabled by default. If you can log in to your Mac with an administrator account, you can enable the root user, then log in as the root user to complete your task.
Re: (Score:2)
Re: (Score:2)
What you want to have as prompt you usually configure in your .bashrc file or what ever shell you use.
While # is traditionally used for root and $ for user accounts, you can set it to anything you want.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
By default the account "root" is disabled, however, if you use this exploit, you enable the root account with no password. The workaround is literally enabling the account and setting the password. I almost freaked out when I found this exploit.
Re: (Score:2)
How can you possibly have a root account without a password?
You certainly can, at least on most *nix flavors. Not the greatest idea though.
Re: (Score:3, Interesting)
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.
Re: (Score:2)
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 ro
Re: Am i missing something here? (Score:2)
Re: (Score:3)
Re: (Score:3)
One can have anything if one has Courage.
Re: (Score:3)
Re: (Score:2)
to prevent reality distortion field implosions (Score:2)
Why the quotes around exploit?
The quotes allow for de-escalation synonym transposition that helps to stabilize the reality distortion field that protects the mac psyche... without it Apple would surely implode.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You first have to be logged in, presumably as an admin user, then try to do anything like change login settings where the user/password authentication pops up. Log in root / no password. It will let you complete the current task... and subsequently log in.
Someone needs to be fired at Apple.
Re: (Score:2)
Do it from a dialog of a logged-in user-- something like the preference pane, lock the "no changes" padlock, unlock it, and use user as root hit unlock...
Re:Can Anyone Here Reproduce This? (Score:5, Informative)
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.
Re:Can Anyone Here Reproduce This? (Score:4, Informative)
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.
Re: (Score:2)
Of course it works via screen sharing.
How should the log on system know that you are doing it via a shared screen and not via the console?
Re: (Score:2)
There are (at least in history) operating systems that use the source of a login to determine whether the login is allowed. Some of these can be configured to block root logins from any source other than the local console. I'm not directly familiar with how MacOS "screen sharing" is tied into the OS (i.e., did a login coming through the "screen sharing" mechanism show a different login source that was used to limit certain behaviors), so it was worth it (to me) to validate that the technique worked via "s
Re: (Score:3)
I wonder if it works when logged in via the guest account (if enabled)?
Re: (Score:3)
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.
Re: (Score:3)
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... [theregister.co.uk]
Re: (Score:3, Insightful)
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... [theregister.co.uk]
Or maybe under Tim Cooks leadership the overall quality of Apples software and hardware has noticeably declined.
Re: (Score:2)
Re: (Score:2)
Or maybe under Tim Cooks leadership the overall quality of Apples software and hardware has noticeably declined.
Under Jobs we got Apple Maps, so bad it could actually kill you. We had numerous testing and quality issues from Apple, like the MacBook 1/4 gallon of thermal paste issue or the classic iPhone 4 antenna "holding it wrong" design flaw.
Even going back to the CRT iMac you had CD-ROM drives with no emergency eject hole, meaning if the disc got trapped you had to disassemble the whole thing (complete with high voltages from the CRT floating around).
Don't mistake the shiny veneer they put on stuff for competence.
Re: (Score:2)
Really? Something to back that up would be nice...
Re: (Score:2)
Re: (Score:2)
"Mac OSX is pretty much the slickest thing out there."
Wet Platinum would disagree with you, there.
Re: (Score:2)
Srsly, dude? Mac OSX is pretty much the slickest thing out there. Which OS, specifically, do you want Tim Cook to give you back? System 7? System 8? Because those were so much better..?
System 7.0.1 was awesome -- I don't know what you're talking about. And Mac OS 8.6 (with the NuKernel and a few cherry-picked Copland features) was damn stable for me too. Much better that MacOS 9, which was only useful for giving FileVault and VoicePrint login demos...
But try to stick 8.6 on Rhapsody and you kind of had a halfway decent OS, ya know?
Re: (Score:2)
Re: (Score:2)
The correct response, as always, is for people to chime in with Mine Works Fine/I've Never Had A Problem posts.
Seems like a pointless thing to show up and say, but tradition is as tradition does.
This isn't an apple-exclusive phenomenon, but they are the masters of it.
Re: (Score:3)
Comment removed (Score:5, Informative)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
First of all, when I ship bugs, I fix them if it's within my abilities to do so. Which is usually is. And I will tell you flat out that if I had billions of dollars in the bank, I'd be able to fix every one that was found, because there are people I could hire that are way smarter than me, and I could hire a lot of them without feeling any pain at all.
My problem with Apple isn't that they ship bugs anyway... it's that they leave serious bugs in place
Re: (Score:2)
I have both a return key and an enter key on my Apple aluminium wired keyboard.
Re: (Score:3)
Re: (Score:2)
You ar an idiot ...
My external keyboard has separated return and enter keys.
My 13" MacBook Air has a RETURN key and pressing it together with "FN" it produces ENTER.
Facepalm ...
Re: Lenny is that you? (Score:3)
Re: (Score:2)
https://wiki.gentoo.org/wiki/C... [gentoo.org]
Re: (Score:2)
Re: (Score:2)
Right.
I got my first computer in Feb, 1978 -- TRS-80.
Discuss.
Re: (Score:2)
October 1979, spend half an hour trying to figure out how to answer "Memory Size?", as it was (IIRC) not in the instruction manual(s). Went Mac in 1985, after a short side-trip through CoCo land to play with 6809 code.
I smugly know that I'm not vulnerable to this because I normally run 10.9. The highest I have is a Mac Mini that came with 10.12 installed, and once I "jail broke" that one, there was no reason to downgrade. I wish companies would quit trying to "re-imagine" operating systems all the time. An
Re: At apple,we care about your privacy and securi (Score:2)
They are not an enterprise company.
and they will tell you this, ad nauseam...any time you have an issue they cant fix.