BigFix solution to major security issue in Apple High Sierra!

Tips
1

Update: Apple has released a fix: https://support.apple.com/en-us/HT208315 (need to update relevance to exclude this version)

  1. Mentioned but noticed 2 weeks before: https://twitter.com/fristle/status/935670476214378496
  2. Announced widely: https://twitter.com/lemiorhan/status/935578694541770752
  3. See the issue: https://twitter.com/patrickwardle/status/935608904377077761
  4. BigFix content within 2 hours: https://bigfix.me/fixlet/details/24857
  5. Apple Patch within 24 hours:

@AlanM

It seems like anyone can use the root user without a password on High Sierra in the currently released version, which is a major problem!

This is a workaround that sets a random password for the root user:

The content says to test all over it, which you should, but it is based upon well tested scripts, so it should be all good.

An additional step is that you can set the root userā€™s shell to ā€œfalseā€ to prevent logins:

It seems like this was mentioned on appleā€™s own forum 2 weeks ago: https://twitter.com/fristle/status/935670476214378496

The manual fix: https://twitter.com/reneritchie/status/935627307565355014

Related:

5 Likes
2

Thanks James! We are testing it out.

1 Like
3

It works well! FWIW, other methods to generate a password might include:

$(uuidgen)

$(openssl rand -base64 32)

1 Like
4

It should be possible to detect if the root user already has a password set using relevance, but I havenā€™t actually figured that part out completely:

arrays "passwd" of dictionaries of files "/var/db/dslocal/nodes/Default/users/root.plist"

This is not complete, a work in progress, see here: https://unix.stackexchange.com/questions/232491/how-to-test-if-root-user-is-enabled-in-mac

5

Wow, @jgstew ā€¦ trying to make sense of plists on macOS and getting nowhere. Stuff like this works:
(keys of it, sizes of arrays of values of it) of entries of dictionaries of files "/var/db/dslocal/nodes/Default/users/root.plist"
but actually getting the data in that array is eluding me. Any pointers?

1 Like
6

I think Iā€™ve got it!

length of string 0 of array "passwd" of dictionaries of files "/var/db/dslocal/nodes/Default/users/root.plist"

This yields results of either 1 or 8 based on my few tests. According to the stackexchange post, 1 = disabled root, 8 = enabled root. Right? So then, the relevance to detect a disabled root account would be:
length of string 0 of array "passwd" of dictionaries of files "/var/db/dslocal/nodes/Default/users/root.plist" = 1

1 Like
7

Yep, you got it. You beat me to it. I was working on this, then left for dinner, and didnā€™t get back to it until now.

It is tough, I feel like I have to relearn it every time. Using number of is very useful.

This is how I would write it for applicability: (plural is best)

exists strings 0 whose(length of it = 1) of arrays "passwd" of dictionaries of files "/var/db/dslocal/nodes/Default/users/root.plist"

In some ways, this might actually be better:

not exists strings 0 whose(length of it = 8) of arrays "passwd" of dictionaries of files "/var/db/dslocal/nodes/Default/users/root.plist"

And for reporting:

lengths of strings 0 of arrays "passwd" of dictionaries of files "/var/db/dslocal/nodes/Default/users/root.plist"
1 Like
8

I just updated the links in the original post at the top to point to the new versions with the new relevance. Thanks!

I donā€™t know if that tweet I linked was the first disclosure of this issue, but if so, I had a workaround posted within 2 hours.

1 Like
9

Just added content to change the root userā€™s shell, which I have not tested:

CC: @sbl

2 Likes
10

So this will create a random password for the root account? Is there a way to make it a specific password or to find out what the created password is?

1 Like
11

It is not hard to make it a specific password. I am intentionally making it a very random password and not storing it in any way so that it is NOT known on purpose.

Setting it to something that is known and the same on all of your computers is a potential security issue, but if that is what you want, just do the following:

wait sh -c "dscl . -passwd '/Users/root' MyP@ssw0rd!"
12

Iā€™d prefer to just set the root user shell to false like you mentioned above. Doing that seems to have resolved the issue without making any password change to the root account.

I do have a question regarding changing the root user shell to false. Would this affect bigfix script usage on that machine in any way or does it just not allow a user to log in as root?

I was under the impression that bigfix ran all scripts as though it were root. Or does it just have root level access?

13

I donā€™t know for certain, but it should just prevent login as root, it should not prevent BigFix from running actions as root.

This will prevent interactive logins as root, but it will not prevent all possible uses of the root account. If you donā€™t set the password and activate the root account, then there will still be possible exploits. Setting the root shell to false is a more conservative approach, but not perfect.

14

Looks like Apple has released a security patch for it.

My understanding is this just disables the ā€œrootā€ user.

15

The fix from apple changes the broken validation that caused the issue in the first place. It probably also disables the root user in case it was turned on due to this issue.

16

So how would we change the root user shell back to true manually?

I assume we could just change ā€˜/usr/bin/falseā€™ to ā€˜/usr/bin/trueā€™ and run that, but if we wanted to make this change on a single machine without running a fixlet how would we go about it?

17

That is covered here: Blocking logins to the root account on macOS High Sierra | Der Flounder

You donā€™t need to change it back unless you have people logging into a mac as root, which you should not have that generally, so this might be a good thing to leave in place as an extra protection.

18

@jgstew - Not that it likely matters anymore now that Appleā€™s released a patch, but it turns out that a computer that has had the flaw exploited also has a passwd of length 8, so the relevance is overly exclusive. Iā€™m looking into what would identify an exploited root.

1 Like
19

yes, that is trueā€¦ I wasnā€™t handling that case.

20

Sigh ā€¦ looks like thereā€™s no difference (that I can find anyway) between root user on a macOS 10.13 computer that has had the password explicitly set and that has had the vulnerability exploited. Guess we just have to deploy the patch.

1 Like