5 ms·

Be careful testing this! It appears that you're creating a "root" superuser with no password. Be sure to clean up that user afterwords. https://twitter.com/a_h

by jcoby 9y ago

Be careful testing this! It appears that you're creating a "root" superuser with no password. Be sure to clean up that user afterwords. https://twitter.com/a_hailes/status/935601901839806464 https://twitter.com/a_hailes/status/935601901839806464

mschuster91 9y ago
The "root" superuser is always there, I'm not sure if it's possible to actually delete it.
- tempay 9y ago
  It is disabled by default[1] (meaning you can't login as it), this vulnerability appears to enable the root user without setting a password. If the root user has already been enabled it doesn't work. Anyone who does this should probably set a password for now and then disable the root user account once it has been patched. [1] https://support.apple.com/en-us/HT204012 https://support.apple.com/en-us/HT204012
  - srathi 9y ago
    This is the best workaround for now. Enable the root user with a strong password till the bug is fixed by Apple.
martinp 9y ago
This support article explains how to disable the root user: https://support.apple.com/en-us/HT204012 https://support.apple.com/en-us/HT204012
- jameskilton 9y ago
  Do note that this doesn't fix the problem. The system (at least High Sierra) will happily re-enable the user for every attempt at logging in.
  - LolWolf 9y ago
    Just change the root password once the account is enabled; this fixes the hole. sudo passwd -u root It's sad we have to do this, though.
  - tekacs 9y ago
    If you disable the root user using `dsenableroot -d` from the Terminal, this seems to disable the account in a way that leaves its password intact.
    - pwinnski 9y ago
      The bug isn't in the disabling, it's in the auto-enabling on attempt.
      - tekacs 9y ago
        Having tested this by both approaches (disabling through GUI & shell), the above (through shell) seems to prevent this from re-occurring when you attempt to perform this bogus login again. Disabling the account via the GUI causes the failure to re-occur.
psychometry 9y ago
You're not creating it, but rather enabling it. When the bug is triggered, the root user is enabled (per Directory Utility).
- fattire 9y ago
  But you are creating the password for it.
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.
- 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.
- 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.
thought_alarm 9y ago
Until this is fixed it's probably better to use Directory Utility to enable root with a strong password. /System/Library/CoreServices/Applications/Directory Utility.app Edit > Change Root Password
ringaroundthetx 9y ago
oh my god

by jcoby 9y ago

mschuster91 9y ago

The "root" superuser is always there, I'm not sure if it's possible to actually delete it.

tempay 9y ago
It is disabled by default[1] (meaning you can't login as it), this vulnerability appears to enable the root user without setting a password. If the root user has already been enabled it doesn't work. Anyone who does this should probably set a password for now and then disable the root user account once it has been patched. [1] https://support.apple.com/en-us/HT204012 https://support.apple.com/en-us/HT204012
- srathi 9y ago
  This is the best workaround for now. Enable the root user with a strong password till the bug is fixed by Apple.

martinp 9y ago

This support article explains how to disable the root user: https://support.apple.com/en-us/HT204012 https://support.apple.com/en-us/HT204012

jameskilton 9y ago
Do note that this doesn't fix the problem. The system (at least High Sierra) will happily re-enable the user for every attempt at logging in.
- LolWolf 9y ago
  Just change the root password once the account is enabled; this fixes the hole. sudo passwd -u root It's sad we have to do this, though.
- tekacs 9y ago
  If you disable the root user using `dsenableroot -d` from the Terminal, this seems to disable the account in a way that leaves its password intact.
  - pwinnski 9y ago
    The bug isn't in the disabling, it's in the auto-enabling on attempt.
    - tekacs 9y ago
      Having tested this by both approaches (disabling through GUI & shell), the above (through shell) seems to prevent this from re-occurring when you attempt to perform this bogus login again. Disabling the account via the GUI causes the failure to re-occur.

psychometry 9y ago

You're not creating it, but rather enabling it. When the bug is triggered, the root user is enabled (per Directory Utility).

fattire 9y ago
But you are creating the password for it.

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.

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.
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.

thought_alarm 9y ago

Until this is fixed it's probably better to use Directory Utility to enable root with a strong password. /System/Library/CoreServices/Applications/Directory Utility.app Edit > Change Root Password

ringaroundthetx 9y ago

oh my god