4 ms·
Now that this is public, it's likely worth passing this message on to non-technical folks too (e.g. share this or write a similar post - this is my only public
by tekacs 9y ago
Now that this is public, it's likely worth passing this message on to non-technical folks too (e.g. share this or write a similar post - this is my only public post):
https://www.facebook.com/amar.sood/posts/10209545863036116 https://www.facebook.com/amar.sood/posts/10209545863036116
- jtokoph 9y agoImportant error in your instructions. They should set a very strong password and keep the root account enabled. Disabling the root account opens up the vulnerability again.
- tekacs 9y agoEdit: Okay so it seems that my shell based suggestion of `dsenableroot -d` prevents the bug from re-occurring, but not the GUI version. :facepalm: I updated the post to include the word 'strong', although I would expect most users to simply set their own password, which should provide identical security to what they currently (should) have. Disabling the root account does not open up the vulnerability again. This vulnerability doesn't reset the root password, it only enables the root account and checks the password against that. The default root password out of the box on OSX is blank which is what allows this to work as-is. By setting a root password, the next time you attempt this (and I tried it), the attempt fails since the 'root' account now has a password set. Disabling simply puts the root account back in a dormant state, where it should be for most users, for after this vulnerability is fixed and it can't be enabled maliciously.
- deleted 9y ago[deleted]