Confirmed... Escalated with my Apple SE...

facepalm.

Just tried this out and not only does it let you login as root but even if you have the account disabled, it reenables it again.

Did this and confirmed it happens here as well.

https://twitter.com/bruienne/status/935607437905809410

Might be good for someone to post how to enable root, set a password, and disable it again for those not in the know. ;)

From what we've tested so far with macOS High Sierra 10.13 and FileVault 2:

1. When a computer boots it goes to the FileVault 2 specific login screen which won't allow you to login as the root user.
2. If a computer logs into an account then locks the computer/sleeps the computer you get a blank username/password login, using root:blank password works in this instance and gets you into the computer, you can then use a terminal to access FileVault 2 user's home directories. It appears that the drive may not be re-encrypting on lock/sleep?

I can confirm that if you have already set a root password, this vulnerability will not work.

I'd already set it on my own computer and could not validate the exploit until I went to another user's computer. Then I generated a random 30 character password and pushed it to all our 10.13 computers that don't already have a root pass set.

So from macadmins slack, a way to stop it from working would be to run

/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false

The above being said, there are ways to still allow a user to elevate their privileges.. This is not a fix but a band aide.

The best fix is enabling a root password..

If anyone is testing this, it will enable the Root account on your machine, this will enable you to log into the machine as Root with no Password. Make sure to disable the account after testing: https://support.apple.com/en-us/HT204012

Just to second that @signetmac posted https://www.jamf.com/jamf-nation/discussions/26290/vulnerability-10-13-root#responseChild156530

Setting the shell to /usr/bin/false is a partial fix, sadly.

Also, root can be enabled as a non-admin too.. & without GUI interaction (as in, you can write a script to make use of the exploit)

Some possible means to mitigate things would be to push a Login Window config profile forcing "List of users able to use these computers" and un-check the box for "Show Other" they should not be able to login as root. FileVault login screen is already just the enabled users but if people log out of a computer instead of shutdown/start up you can have a login window that shows "Other", or if its unencrypted it may just show the blank Username/Password fields. This method does nothing for people logged into the computer enabling this via System Preferences.

Also if root is enabled you can push out a policy with the Local Accounts payload setting the root accounts password to something only known to IT and this would disable the root login with blank password.

Any idea if this is applicable to 10.13 .1 OR just 10.13? Has that determination been made yet...?

Would doing the following resolve the vulnerability... (I grabbed it from this thread - https://www.jamf.com/jamf-nation/discussions/3340/disable-root )

remote the AuthenticationAuthority from the user's account

dscl . delete /Users/root AuthenticationAuthority

Put a single asterisk in the password entry, thus locking the acount.

dscl . -create /Users/root Password '*'

Disable root login by setting root's shell to /usr/bin/false

dscl . -create /Users/root UserShell /usr/bin/false

@steve.summers 10.13.1 is vulnerable too.

Stupid question - anyone tried this on Sierra?

I just tried this in Sierra and could not replicate it.

Not good. I just updated some users to High Sierra.

This only happens on 10.13+

I tried to blog part of the solution process here.

Would this be a useable solution to run via Files and Processes / Execute Command in a Policy?

dscl . -passwd /Users/root 'YourPasswordHere'; dsenableroot -d -u root -p 'YourPasswordHere'

I would read this:

https://derflounder.wordpress.com/2017/11/28/blocking-logins-to-the-root-account-on-macos-high-sierra/

I've written this script to randomize the root pass:

#!/usr/bin/expect
set NewPassword [exec openssl rand -base64 64]

spawn passwd -u root
expect "assword:"
send "$NewPassword
"
expect "password:"
send "$NewPassword
"

puts "
Password Changed."
expect eof
exit 0

This appears in 10.13.1 and the 10.13.2 beta 17c79a (current until today's beta update) as well.

Changing the root password in the manner described by Rich has absolutely no impact on the Jamf Binary to run as 'root', correct?

Correct. The binary runs under the service user you have it set to in the jss.