5 ms·

It's worse than that. You're enabling the root user EVERY time you use this vulnerability. Even if you disable the root user in Directory Utility, logging in wi

by rwc 9y ago

It's worse than that. You're enabling the root user EVERY time you use this vulnerability. Even if you disable the root user in Directory Utility, logging in with root and no password will re-enable the root user.

LeoPanthera 9y ago
You can simply set a root password with "sudo passwd" to close the hole.
- thomastjeffery 9y ago
  Then you better remember the password you set, or be sure that you will always have sudo access.
- tekacs 9y ago
  And you might want to disable the root account again with `dsenableroot -d` as well, so that the root account stays disabled after the vulnerability is patched. Unlike doing this through the GUI, this seems to retain the root password and prevent this vuln from re-occuring.
  - LeoPanthera 9y ago
    Don't disable root. The bug re-enables it with a new blank password.
    - tekacs 9y ago
      It doesn't if you disable it from the shell like this, as I note in my comment. I've tested both approaches - disabling via the GUI causes this bug to re-occur next time you try, disabling via the shell does not.
      - ukblewis 9y ago
        Bizarrely though, you can still use the root user (with the password that you set) to login to the Directory Utility even while it is supposed to be disabled... This behaviour seems super weird.
        tekacs 9y ago
        Yeah I've noticed this myself - I'm on the fence as to whether this is actually disabling the account or simply creating that impression (it does show as disabled in Directory Utility after you perform this command). My hope in recommending people disable this way is that with the additional scrutiny on this subsystem, accounts disabled this way will remain genuinely disabled in a future update. Either way this doesn't seem to reintroduce the bug. ... but the whole thing is a mess overall.
      - kofejnik 9y ago
        I confirm, disabling from shell does seem to prevent further logins
  - skygazer 9y ago
    As far as I can tell, "dsenableroot -d" seems to have no useful effect. After having "* Successfully disabled root user." with it, I can still log in to the root account with the password I set, both at the command line with "login" and from a remote machine via screen sharing. To be flippant, I might say HN discussions seem to QA using Apple methods.
DavideNL 9y ago
...unless you set a password, right?
mcintyre1994 9y ago
I haven't upgraded to High Sierra yet and this doesn't happen on my install atm. Does adding a password to the root user stop this vulnerability? If it does then that seems way better than disabling the account until this is fixed.

by rwc 9y ago

LeoPanthera 9y ago

You can simply set a root password with "sudo passwd" to close the hole.

thomastjeffery 9y ago
Then you better remember the password you set, or be sure that you will always have sudo access.
tekacs 9y ago
And you might want to disable the root account again with `dsenableroot -d` as well, so that the root account stays disabled after the vulnerability is patched. Unlike doing this through the GUI, this seems to retain the root password and prevent this vuln from re-occuring.
- LeoPanthera 9y ago
  Don't disable root. The bug re-enables it with a new blank password.
  - tekacs 9y ago
    It doesn't if you disable it from the shell like this, as I note in my comment. I've tested both approaches - disabling via the GUI causes this bug to re-occur next time you try, disabling via the shell does not.
    - ukblewis 9y ago
      Bizarrely though, you can still use the root user (with the password that you set) to login to the Directory Utility even while it is supposed to be disabled... This behaviour seems super weird.
      - tekacs 9y ago
        Yeah I've noticed this myself - I'm on the fence as to whether this is actually disabling the account or simply creating that impression (it does show as disabled in Directory Utility after you perform this command). My hope in recommending people disable this way is that with the additional scrutiny on this subsystem, accounts disabled this way will remain genuinely disabled in a future update. Either way this doesn't seem to reintroduce the bug. ... but the whole thing is a mess overall.
    - kofejnik 9y ago
      I confirm, disabling from shell does seem to prevent further logins
- skygazer 9y ago
  As far as I can tell, "dsenableroot -d" seems to have no useful effect. After having "* Successfully disabled root user." with it, I can still log in to the root account with the password I set, both at the command line with "login" and from a remote machine via screen sharing. To be flippant, I might say HN discussions seem to QA using Apple methods.

DavideNL 9y ago

...unless you set a password, right?

mcintyre1994 9y ago

I haven't upgraded to High Sierra yet and this doesn't happen on my install atm. Does adding a password to the root user stop this vulnerability? If it does then that seems way better than disabling the account until this is fixed.