Seems to be something related to a backwards-compatibility code path for upgraded systems. According to multiple posts on this thread it only affects systems upgraded to High Sierra, not fresh installs. See https://news.ycombinator.com/item?id=15802622 for example. Adding extra layers for compatibility complicates testing and debugging. With this many eyes on it hopefully someone will be able to deduce exactly what's going on.

My High Sierra is a fresh install, and it's affected.

Yup. Can confirm. I installed it fresh on a VM from the downloaded installer and it is affected.

My upgraded high sierra doesn't have this problem. The theory could be backwards. Anyways, this is stunning.

Note that I had to try twice for this to "work" - maybe try again. Incredible.

EDIT: apparently, the first login attempt with root enables root login with whatever password is provided. Then, when you try again, login will work.

If that's true, we have a combined diagnostic and workaround:

Try logging in with root and a good password. It should not work (if it does, root with that password had been enabled before).

Now, try logging in again with root and that same password.

If it works, your system was vulnerable to that bug, but you've now fixed the problem, as you've enabled root and set a good password (so nobody else can log in unless they find that password).

If it doesn't work, it looks like root has been set up before with some other password (maybe empty), and it's conceivable that someone has exploited that bug on your machine before.

Is that understanding correct?

Try guest account.

I could do it on guest account, by first pressing enter after entering "root". And after a fail, clicking the unlock button.

Mine is an upgrade and does.

But at one point a root account is created with an empty password right?

There's a specific line somewhere that's doing this, in theory.

Maybe they should have opted for "create `root` with unguessable password"

No, that's a hack. And it opens new attacks, like on the hashing algorithm and poor randomness or predictability in the generation logic.

You have some pretty high standards. Being imperfect doesn't automatically make it better than the alternative of not doing it.

If the system can't generate a secure hash, or can't generate cryptographically random numbers, you're in serious trouble. Those tools are foundational to security.

Moving the problem from "a root account is created with the first password you try" to "you have to break crypt(1) or /dev/random" is basically equivalent to solving it.

Maybe something like this was added to make debugging/testing of the OS easier? maybe they just forgot to remove it before shipping the new macOS

Apparently it is not just enabling root, but setting the password the first time you do it (in other words, the blank value has nothing to do with it). Then the subsequent times it'll use the pw you set the first time.

That seems the only probable cause I've come across so far. It doesn't seem to be a backdoor because it would be more of a back-spillway-gate.

That could be the case - I can't find any other possible logical explanation, because it doesn't make any sense.

I'm having a hard time understanding how this could happen too.

It would have to be that looking up the root account enabled it, maybe users go dormant or something, and this was a way to readd them? then once it was enabled it defaulted to a blank password, but you would think that it needs sudo to enable root in the first place.

Blank password is not necessary. Any password provided on initial attempt WILL BECOME the root password. Blank is being circulated simply because that's what was discovered first.

Edit: Which also means it's possible to "secure" a vulnerable (unexploited) machine simply by attempting to log in as root with a long random password.

So by my logic - if you tried this exploit and it failed the first time, then worked the second time: No one else has tried it before you. Otherwise it would either have worked the first time (if you guessed the same pass) or not worked at all (if the first time it was tried a different pass was used).

Or is this not a permanent password set?

Well, I suppose if someone had exploited your system with this, they could probably install some remote access tool, and then disable the root account and unset the password, and remove all evidence they were there.

But, if you don't have Screen Sharing or Remote Management enabled and exposed to the WAN, you're probably safe unless someone untrusted had physical access.

It's hard to know how long this vulnerability was "known." The initial report on Nov 13th looks second hand, so it may have been circulating earlier.

If that's true (and certainly sounds plausible from what is known so far), that's a very valuable heuristic.

Not only enabled it but actually set an empty-string password. Usually the stored hash for a disabled account is not in the hash space, so it was either overwritten, or root account password was actually empty string out of the factory. That and the enabling of the account both point to debug code accidentally left in (or intentional backdoor by the disgruntled).

Login screen is probably already running as root in the first place, so it already had permission to enable shell/GUI access

This seems to be why: https://objective-see.com/blog/blog_0x24.html

To some up, when you try to log in with a disabled account, MacOS "promotes" the account but uses the _password provided by the user trying to log in_ instead of the password on file (in this case, an asterisk indicating the account is disabled). Once that is done, you can log in with that account.

IMHO these are two separate bugs: promoting disabled accounts and using the password the user typed in instead of the value in the password list.

I assume that it can't use the password in the password list as that should be hashed already.

I see your point, but it still seems kind of wacky to me. They should validate that the password is correct, then promote the account. Taking the password provided in the authentication dialog just seems like a bad idea.

Perhaps the root issue here is forgetting that the asterisk indicates that the account is disabled and shouldn't be a candidate for promotion.

I'm reminded of: "Solaris Telnet 0-day vulnerability", 2007: https://m.slashdot.org/story/80056

But this does indeed seem to be an extra level of user-friendly stupid.

Like an illusionist hiding the truth, this bug too will have a logical explanation that will leave us in wonder for as long as we aren't told how it happened.

Identity management is complex and boring.

Apples user management is even more complex than most Unixes.

OSX user management is weird. At least on prev versions, they don't show a root account in the Users & Groups ui.

A guess: there's a code path in the UI that is only tested on "mac" accounts, not the root account that the system requires to exist. Something about the non-macness of the root account interacts badly with the UI that expects to be run on a mac users account.

You misunderstood. He's talking about a password hash storage system, not a filesystem.

Exactly, how can this happens and no one asks.

And that will help because Open Source security is so great?

Or because people care to inspect the codebases they otherwise use?

I don't think you understand the difference between open source and free software. Allowing everyone to read it makes it open source.

https://www.gnu.org/philosophy/open-source-misses-the-point....