But I'm breaking my brain trying to figure out how in the hell a login attempt for "root" will enable it if it's disabled. Why is this is a possibility, to just enable root, no questions asked?
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?
I could do it on guest account, by first pressing enter after entering "root". And after a fail, clicking the unlock button.
There's a specific line somewhere that's doing this, in theory.
Maybe they should have opted for "create `root` with unguessable password"
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.
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.
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.
Or is this not a permanent password set?
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.
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.
Perhaps the root issue here is forgetting that the asterisk indicates that the account is disabled and shouldn't be a candidate for promotion.
But this does indeed seem to be an extra level of user-friendly stupid.
Apples user management is even more complex than most Unixes.
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.
Or because people care to inspect the codebases they otherwise use?
https://www.gnu.org/philosophy/open-source-misses-the-point....