7 ms·

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

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.

devindotcom 9y ago
I was wondering about that. I'm going to change this.
- deleted 9y ago
  [deleted]
- eganist 9y ago
  Thanks :)
AdamJacobMuller 9y ago
Enables root access in what way?
- selectodude 9y ago
  Mac OS X doesn't have a real root account, it uses sudo exclusively. This enables a true root user shell.
  - AdamJacobMuller 9y ago
    The root account always exists. 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.
    - arghwhat 9y ago
      Your comment suggests that it is related to users with older, pre-High Sierra directory entries. That is, upgraded rather than freshly installed machines that leave older, pre-ShadowHashData intact. Is this correct?
      - Asmod4n 9y ago
        Works with El Capitan too.
      - jsmthrowaway 9y ago
        No, I reproduced on freshly-installed High Sierra on two machines.
        arghwhat 9y ago
        Odd. No reasonable amount of attempts would reproduce it on my wife's few-weeks-old work machine, where the root user was visibly disabled. 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).
      - AdamJacobMuller 9y ago
        No, sorry, I did not mean that or mean to imply it. 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.
        arghwhat 9y ago
        Ah, yes, but that is what I meant in suggesting that it was related to a High Sierra upgrade. 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)...
- deleted 9y ago
  [deleted]
CrendKing 9y ago
This bug exists regardless of user reproducing it or not. If there is anything good, reproducing it actually brings awareness to the user (make them change the password maybe). Hacker will "enable" the root user anyway. What should be done is that Apple releases fix to this problem.
- devindotcom 9y ago
  Yeah that was my thought initially too but there may be invisible ways to leverage an existing root user that we're not aware of. After all, this bug exists...
  - stingraycharles 9y ago
    The issue is that the bug leaves a password-less root account available through other means as well. Once you try to reproduce the bug, an attacker could potentially do a remote root login without password. As such, it's very dangerous for people to try to verify and should be strongly discouraged.
    - mcintyre1994 9y ago
      If you have remote login enabled does root/no password not work already because of the bug? It apparently does from the login screen if you have username/password mode on, so I wouldn't be surprised if it worked over remote login by default.
      - djrogers 9y ago
        Does not work via ssh or screen sharing based on my testing here. Seems to require physical access to the machine.
        mcintyre1994 9y ago
        Does seem to work with some software: https://mobile.twitter.com/patrickwardle/status/935639234437935105 https://mobile.twitter.com/patrickwardle/status/935639234437...
hw 9y ago
There’s no need to do this yourself to verify it. Doing so creates a “root” account that others may be able to take advantage of if you don’t disable it. That should be much higher up in the article.
- geoelectric 9y ago
  I really wish it had been. I had no idea it was something that A) left droppings, and B) actually enables direct login from boot with root/no pw once you've done it. 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.
- FabHK 9y ago
  Wouldn't it make sense to propose this combined diagnostic and workaround: 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?
sephicr 9y ago
Yes, but the most secure thing to do at this point _is_ to recreate the bug and then set a password for the root user. Otherwise the hole is still there for others to exploit.
- pilsetnieks 9y ago
  If you set a root password, this bug still works, it seems to reset the root password. Edit: I was partly wrong. The bug still works if you disable root afterwards, then it reenables and resets it.
  - ukblewis 9y ago
    Yeah, you’re safe if you keep the foot account alive and you set a password for root. At least as far as I can tell...
kreeWall 9y ago
Can you talk about how to correctly disable the root account if someone did try it?
- martin-adams 9y ago
  If you're wondering how to disable it, the menu option can be found here: https://support.apple.com/en-gb/HT204012 https://support.apple.com/en-gb/HT204012
  - mediocrejoker 9y ago
    According to another comment thread here https://news.ycombinator.com/item?id=15802113 https://news.ycombinator.com/item?id=15802113 disabling from the GUI re-enabled the bug. 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
thomastjeffery 9y ago
It can already be activated remotely: https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroundsquirrel https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroun...

devindotcom 9y ago

I was wondering about that. I'm going to change this.

deleted 9y ago
[deleted]
eganist 9y ago
Thanks :)

AdamJacobMuller 9y ago

Enables root access in what way?

selectodude 9y ago
Mac OS X doesn't have a real root account, it uses sudo exclusively. This enables a true root user shell.
- AdamJacobMuller 9y ago
  The root account always exists. 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.
  - arghwhat 9y ago
    Your comment suggests that it is related to users with older, pre-High Sierra directory entries. That is, upgraded rather than freshly installed machines that leave older, pre-ShadowHashData intact. Is this correct?
    - Asmod4n 9y ago
      Works with El Capitan too.
    - jsmthrowaway 9y ago
      No, I reproduced on freshly-installed High Sierra on two machines.
      - arghwhat 9y ago
        Odd. No reasonable amount of attempts would reproduce it on my wife's few-weeks-old work machine, where the root user was visibly disabled. 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).
    - AdamJacobMuller 9y ago
      No, sorry, I did not mean that or mean to imply it. 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.
      - arghwhat 9y ago
        Ah, yes, but that is what I meant in suggesting that it was related to a High Sierra upgrade. 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)...
deleted 9y ago
[deleted]

CrendKing 9y ago

This bug exists regardless of user reproducing it or not. If there is anything good, reproducing it actually brings awareness to the user (make them change the password maybe). Hacker will "enable" the root user anyway. What should be done is that Apple releases fix to this problem.

devindotcom 9y ago
Yeah that was my thought initially too but there may be invisible ways to leverage an existing root user that we're not aware of. After all, this bug exists...
- stingraycharles 9y ago
  The issue is that the bug leaves a password-less root account available through other means as well. Once you try to reproduce the bug, an attacker could potentially do a remote root login without password. As such, it's very dangerous for people to try to verify and should be strongly discouraged.
  - mcintyre1994 9y ago
    If you have remote login enabled does root/no password not work already because of the bug? It apparently does from the login screen if you have username/password mode on, so I wouldn't be surprised if it worked over remote login by default.
    - djrogers 9y ago
      Does not work via ssh or screen sharing based on my testing here. Seems to require physical access to the machine.
      - mcintyre1994 9y ago
        Does seem to work with some software: https://mobile.twitter.com/patrickwardle/status/935639234437935105 https://mobile.twitter.com/patrickwardle/status/935639234437...

hw 9y ago

There’s no need to do this yourself to verify it. Doing so creates a “root” account that others may be able to take advantage of if you don’t disable it. That should be much higher up in the article.

geoelectric 9y ago
I really wish it had been. I had no idea it was something that A) left droppings, and B) actually enables direct login from boot with root/no pw once you've done it. 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.
FabHK 9y ago
Wouldn't it make sense to propose this combined diagnostic and workaround: 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?

sephicr 9y ago

Yes, but the most secure thing to do at this point _is_ to recreate the bug and then set a password for the root user. Otherwise the hole is still there for others to exploit.

pilsetnieks 9y ago
If you set a root password, this bug still works, it seems to reset the root password. Edit: I was partly wrong. The bug still works if you disable root afterwards, then it reenables and resets it.
- ukblewis 9y ago
  Yeah, you’re safe if you keep the foot account alive and you set a password for root. At least as far as I can tell...

kreeWall 9y ago

Can you talk about how to correctly disable the root account if someone did try it?

martin-adams 9y ago
If you're wondering how to disable it, the menu option can be found here: https://support.apple.com/en-gb/HT204012 https://support.apple.com/en-gb/HT204012
- mediocrejoker 9y ago
  According to another comment thread here https://news.ycombinator.com/item?id=15802113 https://news.ycombinator.com/item?id=15802113 disabling from the GUI re-enabled the bug. 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

thomastjeffery 9y ago

It can already be activated remotely: https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroundsquirrel https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroun...