Huge security flaw lets anyone log into a High Sierra Mac

Tech Crunch ^ | Nov 28 2017 | Kevin Coldewey

[Swordmaker]

This has to be fake news. I am sure someone will be along shortly to wave their hands and tell you it is all just an illusion of old and out of date info.

Unfortunately, it is not fake news. It does what it says it will. One DOES have to be in Admin to do it. . . and most people do not run in Admin mode if they are smart.

[Swordmaker]

I’m running 10.13.1 and this bug doesn’t seem to affect me. Perhaps it only affects certain models? In any event Apple should sort it out soon. Agree this is something that never should have gotten out the door.

If you are running as a Standard User, it won't work. You have to start from running as an Admin. . . then it works. But, most people, likely like you, are running in Standard mode where it's safer to browse the Internet. A standard user cannot invoke ROOT.

[grey_whiskers]

This is a stupid oversight. What it essentially is, is that it has always been an ability of an Administrator User to create a ROOT USER but it should not allow that event to occur without also requiring the input of a password before enabling the Root capabilities.

Creation of normal users can occur without passwords, but this one should NOT ever be allowed without a password and in the past it has been required for this. Apparently, someone was working on this and disabled to forced PW and it did not get re-enabled in the release. The good news is that it requires an Administrator level user to create a Root user, and also physical access to the computer.

It’s an easy fix, and Apple will be pushing out an update that will address it very quickly by returning the password requirement.

Well, as long as they don't hire John Podesta...or the Awan brothers.

[dayglored]

> This is a stupid oversight.

Yes, it’s stupid, but it’s more than an oversight.

First, someone (presumably an engineer debugging something) disabled a security feature, but they failed to revert it when they were done, and they committed the change to the source repo. Well, that’s bad. But sh*t happens, bad commits do happen. It was not terrible at this level — it should have gotten caught and corrected at the next level.

Then at the next level, whoever was supposed to review commits missed it. That’s worse than the original mistake. The error became considerably worse because now it’s assumed to be okay.

Then the error was built into the release, and QA failed to test for it. This is egregious. QA shouldn’t have to find this kind of error — you can’t “test software until it works”. But even so, this wasn’t a difficult bug to exercise, if you have the resources of Apple. My God, they’ve got hundreds of QA people, they’ve got automated testing setups. But still, QA didn’t find it.

More than an oversight. This was a systemic failure of the first order.

BTW, I’ve done professional industrial strength software testing since the late 1970’s, so I get to be a little righteous about this one. I’m very disappointed in Apple and I expect them to fire a few people over this.

[Eric in the Ozarks]

My Mac is from 2010. I downloaded High Sierra two weeks ago.
No issues...

[TheStickman]

Stuff like this is why I never upgrade to the newest version of macOS has been out for at least a year.

[Swordmaker]

Apparently there is more to this problem than just allowing Root with no password. Root is enabled by default in the latest macOS High Sierra. That is a huge departure from previous macOS and OSX versions where it was always disabled by default.

Here is how to protect yourself against YOU or anyone exploiting this vulnerability. It is as simple as disabling the Root user.

1. Log into your Mac as an Administrator
2. Open System Preferences
3. Select Users and Groups
4. Unlock the pane by Clicking on the Padlock Icon and entering the Admin User Name and Password
5. Click on Log in Options
6. Click "Join" Network Account Server:
7. Click on Open Directory Utility
8. Unlock this pane by Clicking on the Padlock Icon and entering the Admin User Name and Password
9. Under the Directory Utility Menu Bar, select Edit then click and release on Disable Root User
10. Lock the Padlock Icon on the pane
11. Close the Utility Directory pane window by clicking on the Red Dot
12. Lock the Users & Groups Preference pane
13. Close the Users & Groups Preference pane by clicking on the Red Dot.

Once you have done this, the Root User Abilities are closed down and have to be re-activated by repeating the above procedure and clicking on the drop down menu to ENABLE ROOT USER. . . and ADD a password.

[Swordmaker]

If you want to KEEP Root enabled and make it safe, follow the above proceedure, but use the drop down menu but select Change Root Password. . . and enter a good, complex password.

[Swordmaker]

See the procedure to fix this problem above:

[Swordmaker]

So, after doing some digging, the problem is NOT that the code allows creation of root abilities without a password, but that the ROOT USER is ALREADY enabled with no password under the name ROOT or root. . . and was installed on all macOS 10.13.1 installs.

It's not a problem with the root creation but with the update install being left with a root user still active without a password!

DUMB, DUMBER, and DUMBEST!

Industrial Strength STUPID by someone who just did not look! And some idiot who forgot to DISABLE THE F'ING ACCOUNT in the Gold Master!!!!

Not to mention those in QA, as dayglored pointed out, who just did not notice when they went in and enabled their own ROOT ACCOUNTS that it was already enabled!

[for-q-clinton]

How the heck did they even let this happen? Users are stupid they will screw this up.

[for-q-clinton]

Actually post 8 pointed out quality review failure first 😁. This is like Microsoft 1990 dumb.

[Swordmaker]

More than an oversight. This was a systemic failure of the first order.

Oh, I agree. I think someone really screwed up. But who thinks about checking to see if a null password is acceptable when it was not OK before, especially in something as obscure as creating Root user ability? It's one of those things only 1 in ten thousand users ever do and then those only do it once. It is not something a user does repeatedly and it is not something one does on a Mac over and over again to test. It's actually a pain in the rear to undo so one can try again because once the root user is created, password is set and can only be changed.

As you can see above, I finally figured out what is REALLY going on with this "vulnerability." It's not a true coding error that allows the creation of a new root user without a password, it's that someone left their Root User account open with no password and it wound up in the Gold Master.

That's the only thing that meets the criteria of how this "vulnerability" works. . . and the "root" user is in the user list. This isn't "creating" a root user, it's only invoking an already existing root user.

[IndispensableDestiny]

Apparently there is more to this problem than just allowing Root with no password. Root is enabled by default in the latest macOS High Sierra. That is a huge departure from previous macOS and OSX versions where it was always disabled by default.

Now that I've played with it for a while, the problem is not that root is enable by default. The problem is that attempting root several times (in my case two) allows root with the root password -- which is null by default. If root had been disabled, you will find it now enabled.

If you go back in disable root and attempt the root flaw again, it will re-enable root and let you in with whatever password you has set earlier, or null if not set.

[dayglored]

> ...it is not something one does on a Mac over and over again to test. It's actually a pain in the rear to undo so one can try again...

As dayglored looks up quietly from his work and muses, "Now, if I were creating a backdoor that would slide through QA test, what characteristics would it have to have...?"

Just sayin'... If only 1/10th of 1% -- 1 in a thousand -- Muslims is a terrorist, that's 1,800,000 terrorists in the world.

So if you've got 123,000 employees (as Apple does, per Wikipedia), and only 1/10th of 1% -- 1 in a thousand -- is unscrupulous, in the pay of a competitor or foreign agency, that's 123 employees who might do something that egregious.

[Swordmaker]

How the heck did they even let this happen? Users are stupid they will screw this up.

I'd say it happened because invoking a ROOT USER is something only 1 in 10,000 Mac users ever do, and when they do it, they only need to do it once.

It is not something that is ever done repeatedly. Ergo, a Mac user who might need Root will go in to activate it and click on Enable Root, then they'd add a root user password and then hit the Enter button.

They most likely would never even notice that there was already an existing user with a blank password.

[for-q-clinton]

Wow that is really bad. So the work around won’t fix this?

Better lock your Mac up until this is fixed.

[TXnMA]

"But the Apple fan bois on FR told us that Apple is perfect."

LIE!!!

Post a link to validate that statement, or STFU and GTHO!

[for-q-clinton]

Nah...there’s something much worse about this scenario.

[Swordmaker]

Now that I've played with it for a while, the problem is not that root is enable by default. The problem is that attempting root several times (in my case two) allows root with the root password -- which is null by default. If root had been disabled, you will find it now enabled.

Let me try that, IndispensableDestiny, I had disabled root on my MacBook and tried it several times and it did not turn back on as yours did, but let me try several more times... and see if I can replicate your experience.