Encouraging users to "try it" is dangerous here. Recreating the bug enables root user across the system, and most users won't know how to disable it.
TechCrunch, if you're reading this... please discourage people from reproducing the bug.
TechCrunch, if you're reading this... please discourage people from reproducing the bug.
That should be much higher up in the article.
Apple's going to have to nuke everyone's root account on an update. I don't see any other solution that won't leave a shitload of machines with open root accounts from trying the fun tweet and then never setting a pw.
1. Try logging in with root and a good password. It should not work (if it does, root with that password had been enabled before).
2. Now, try logging in again with root and that same password.
2a. 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).
2b. If it doesn't work, it looks like root had 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?
What should be done is that Apple releases fix to this problem.
As such, it's very dangerous for people to try to verify and should be strongly discouraged.
Once you enable root access - by 'testing' this - others can remotely & silently access the system as root.
GP is right - don't encourage people to test this, as there's nothing to gain from it. If you're on a shared machine you need to mitigate. If you're on your own dedicated machine you need to not share it until this is fixed.
That's not accurate. The user appears to be there either way, but attempting to log in to a machine remotely using 'root' and no password does not work - even after doing the preference pane thing...
root account is 'there' all the time, yes. This process enables the account proper (rather than just sudo). Evidently some remote mechanisms using root work after the account is enabled.
They already can:
https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroun...
Source: Just tried it myself.
Really bad stuff
I'm advising folks (incl. non-tech) to set a root password and then re-disable the account (specifically via shell), which prevents this from re-occuring:
Once done, you have opened for root without password globally. That's bad.
What they should do, as responsible disclosure dictates, is report it in secret to apple, and at most publicize a workaround (activate root user, set password) without reporting the details of the vulnerability.
EDIT: It does not appear to be limited to admin users. It appears to be related to disabled root accounts of older origin, such as through upgrades. I cannot reproduce on a fresh High Sierra install, but I reproduced on an upgraded install.
Somebody in Turkey has no expectation that they will be treated with respect. It's much more likely they will be attacked as in "shoot the messenger." (So, please don't attack the person who brought this to our attention.)
I think they made a reasonable decision, due to the critical nature of this bug, and tweeted about it.
The DMCA is a disgusting and absurd set of laws that can always make me angry. Its existence alone proves very much how big companies can rule with money, placing capitalism over democracy.
In my opinion, there's a point at which it becomes irresponsible to let them sit on issues for so long, but their newspeak for the disclosure policy tries to pre-empt that idea.
But yes, responsible disclosure includes a deadline (60 days?). Flexibility granted if the company truly needs it, and the nature of the vulnerability requires discretion until fixed. A major widespread flaw with no workaround short of air-gapping the machine would be wise to keep secret until fixed.
Microsoft are the other big one.
The "right" thing is far more complicated than people who have no experience working with vendors to fix bugs like to assert.
There is some game theory here. The rationale is that if vendors know that GPZ will sit on their vuln until it is fixed, they are not forced to take the deadline seriously. For that reason, GPZ must remain firm on their deadlines, and everyone knows that if you try to call their bluff, you are going to lose that bet and have an even bigger mess.
https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroun...
Otherwise the hole is still there for others to exploit.
Edit: I was partly wrong. The bug still works if you disable root afterwards, then it reenables and resets it.
On my laptop I was able to exploit the bug from the local GUI and then disable it from happening (as far as I can tell) by changing the root password from the shell with sudo passwd root and then disabling the root user altogether with dsenableroot -d
Playing around with disable/enable and the exploit: Root always has a /bin/sh shell "Disable root user" removes the ShadowHashData from the directory services entry for root The bug sets ShadowHashData to the hash of an empty string.
Now, ShadowHashData is a complex DS entry. I've never seen passwords represented this way in other OSX versions. I think this password storage format is new.
I strongly suspect the bug here is one related to OSX attempting to upgrade the password to the new storage format and when it does that, it inadvertently stores the password with a hash of null.
This should be very trivial for Apple to fix that (and thus "disable" the root user) by just removing any ShadowHashData that is solvable by an empty string.
The factors that differed from my laptop, where it worked until I set a root password, as that her machine was a fresh install, and she is not admin (a managed machine).
I think the feature that caused this is related to upgrading pre-high-sierra user password hashes to high-sierra-style hashes.
The fact that it works for situations where the password is null is a/the bug.
If we assume that ShadowHashData hash was introduced in High Sierra, I thought it was safe to assume that a crypt hash would only origin from a pre-High Sierra install. Unless, of course, they are used as some form of default value (such as when disabling the user)...