Vulnerability 10.13 - Root

[rderewianko]

Since this is out there, and the original finder did not go through responsible disclosure. Figured i'd post it here so at least admins are aware.
https://twitter.com/lemiorhan/status/935578694541770752

Dear @AppleSupport, we noticed a HUGE security issue at MacOS High Sierra. Anyone can login as "root" with empty password after clicking on login button several times. Are you aware of it @Apple?

This works on User & Admin accounts.

That being said, if you enable root and have a password on it. You're not affected. If you don't it'll enable root and create an account.

Enabling a root password however may cause you more tech debt down the line.

[donmontalvo]

@tsossong pretty sure you'd need admin rights to delete the file to get admin rights. Or am I missing something? :)

[donmontalvo]

@doggles excellent script, we made a couple changes, including setting shebang to #!/bin/sh, and closing the tag in the last line echo "<result>$RESULT/result>". #etherBeerForYou

[geoffrepoli]

@tsossong, the issue is that any user could screenshare to any other discoverable Mac on the network with ARDAgent running and log in as root. At least for our situation, the biggest threat vector is other employees.

@donmontalvo, good eye, closed the XML tag. Shebang won't make a difference, just a habit of mine to use /usr/bin/env bash. I try to avoid calling wih /bin/sh when the script contains bashisms ([[ ]]). Though macOS, the shells are the same except for echo -e AFAIK.

[McAdams]

Great suggestions and scripts. I can confirm this is fixed in beta 4 & 5 of High Sierra.

[kcranford]

Be warned. I discovered, and have confirmed on a few sites, that if you disable root the exploit returns. When you set the root password you need to keep the account enabled.

[kentmj]

So is JAMF going to change their OS whitepaper that says "you should upgrade to the latest OS on day one"?

[charlesteese-mf]

@stas21 you can use the same script to later change it to a set password (just set NewPassword to a string) or use the

dsenableroot -d

command once this issue has been fixed.

[demaioj]

I see a few posts here with scripts to make random passwords for root. Sorry if this sounds stupid but I'd like to make sure there is no reason I would ever need the root password? Luckily we've only had a few users upgrade to High Sierra before it was blocked.

[jstine]

Why is everyone using scripts when this seems to fix the issue? Using scripts to randomize the password instead of setting a single password for everyone?

[jrwilcox]

Its difficult to log in to all 16,000 macOS devices.

[charlesteese-mf]

@jstine I don't want all my devices to share a root password, I want it to be long and randomly generated.

[donmontalvo]

@kentmj wrote:

So is JAMF going to change their OS whitepaper that says "you should upgrade to the latest OS on day one"?

This. :)

[rderewianko]

@jstine while that way works, it doesn't tell the root user to use a different shell. That way would also show the user at a login window, while enabling it through CLI should not.

[donmontalvo]

@McAdams wrote:

Great suggestions and scripts. I can confirm this is fixed in beta 4 & 5 of High Sierra.

Are we sure? Doesn't seem to be.

[rderewianko]

It is not fixed in beta 4/5. I've seen a lot of reports saying no.

[gersteina1]

Just got an email from Apple:
APPLE-SA-2017-11-29-1 Security Update 2017-001

Security Update 2017-001 is now available and addresses the
following:

Directory Utility
Available for: macOS High Sierra 10.13.1
Not impacted: macOS Sierra 10.12.6 and earlier
Impact: An attacker may be able to bypass administrator
authentication without supplying the administrator’s password
Description: A logic error existed in the validation of credentials.
This was addressed with improved credential validation.
CVE-2017-13872

When you install Security Update 2017-001 on your Mac, the build
number of macOS will be 17B1002. Learn how to find the macOS version
and build number on your Mac at https://support.apple.com/HT201260.

If you require the root user account on your Mac, see
https://support.apple.com/HT204012 for information on how to enable
the root user and change the root user's password.

Information will also be posted to the Apple Security Updates
web site: https://support.apple.com/kb/HT201222

[keaton]

Security Update 2017-001 is out that fixes the issue. No reboot is required.
https://support.apple.com/en-us/HT208315

[john_sherrod]

Apple now has a patch out: https://support.apple.com/en-us/HT208315

[MandyDroid]

Yay for patches - life contiunues...
https://support.apple.com/en-us/HT208315

[jhuls]

Until I can test something firsthand it's tough to trust anyone here who says it's been fixed. As an example I'm seeing people report that they can't reproduce the exploit but I'm guessing they're only trying to do it one time. When I tested yesterday, I initially couldn't reproduce the bug until I tried it more than once. This was the case each time I disabled root and tried it again. It always took more than one attempt.

[gersteina1]

But the fix only applies to 10.13.1.

[mm2270]

Would have been nice if Apple made the fix available to 10.13.0 systems as well, since not everyone may be on 10.13.1 at this point. If anyone has any users still on 10.13.0, you'll need to get them or force them to update to 10.13.1, which involves a reboot of course, and then push the security update to them.

[Taylor_Armstron]

I think this is a big enough issue to warrant upgrading to 10.13.1 out-of-band if necessary.

We're still on 10.12, so not affected, but I'd do a .1 update in a heartbeat to resolve this if we were.

[fraserhess]

Has anyone found a pkg download of 2017-001 to push out with JAMF?

[keaton]

@hessf It can be downloaded here. - Source

One thing to note is this update will be downloaded and installed automatically on all Macs running 10.13.1 so you should not need to push it out with Jamf.

[fraserhess]

@keaton Thanks.

Will it be automatic because it's supplemental? I manually installed at the CLI on my High Sierra reference computer where automatic software updates are off.

[keaton]

@hessf From my understanding it will get installed either way.

Source 1, Source 2

[abtsux]

Is there a reason why you wouldnt just create a policy that uses the built in ability to reset an account password instead of using a script?

[alexjdale]

For some reason I can't seem to install the update from the command line. The softwareupdate command will show me the update when I get a list of available updates, but when I go to download or install it, it says it doesn't exist.

[mm2270]

@alexjdale Seeing the same thing. It shows up in a very odd way on the command line. There's an extra - at the end of the update name, as if it's missing some extra characters. I tried it several different ways, with/without the dash, with/without both single and double quotes around the update name. Fails every time saying "No such update". Oy.
I haven't tried doing just a sudo softwareupdate -ia to install everything yet, but that may work (or may not). What a mess.

[alexjdale]

Yup, I wonder if it's a catalog issue on their end? I hope their forced update process works well.

[jedi1yoda1]

The command I used for getting it to work within the Software Update CLI:

softwareupdate -i "Security Update 2017-001- "

It seems there is an extra space at the end of the label.

[alexjdale]

Nice find, that was it. Too bad my usual patching script can't handle trailing spaces, but that's fixable.

[kquan]

if you run on terminal for high sierra, it should/could be sudo softwareupdate -dia

once applied, you can confirm on terminal using sw_vers :

Should output something like :

ProductName: Mac OS X ProductVersion: 10.13.1 BuildVersion: 17B1002

[mjhersh]

Perhaps this is all moot now that Apple's patched, but I wrote a shell script that can be used as an extension attribute. It detects one of 5 states of machines:

1. "Not affected" - not running High Sierra
2. Patched - Running High Sierra, already has Apple's security update
3. Vulnerable - Running a vulnerable OS, but not yet exploited
4. Exploited - Running a vulnerable OS and someone has already exploited it
5. Secure - Running a vulnerable OS, but secured through other means (like rtrouton's script)

dscl . -read /Users/root passwd will return * on a machine with no password set for root and ******** on a machine with any password (including a blank password) set. So if it's just * on a vulnerable OS, I know the system is vulnerable but not yet exploited. If it's been exploited, that password would be set and it would show ********. If that's the case, I attempt to authenticate as root with a blank password to see if the machine is exploited or secured.

I hope someone finds this useful.

#!/bin/bash
buildver=$(/usr/bin/sw_vers -buildVersion)
major=${buildver:0:3}
minor=${buildver:3}

if [[ "$(/usr/bin/sw_vers -productVersion)" != "10.13"* ]]; then
    # Not High Sierra, so not affected
    echo "<result>Not affected</result>"
    exit 0
fi
if [[ "$major" > "17B" ]] || ( [[ "$major" = "17B" ]] && [ "$minor" -ge 1002 ] ); then
    # Already patched by Apple
    echo "<result>Patched</result>"
    exit 0
fi
if [ "$(dscl . -read /Users/root passwd | awk '{print $2}')" = '*' ]; then 
    # Vulnerable, not yet exploited
    echo "<result>Vulnerable</result>"
else
    result=$(sudo -u 'nobody' /usr/bin/osascript -e 'do shell script "/bin/echo Exploited" user name "root" password "" with administrator privileges' 2>/dev/null)
    if [ "$result" = 'Exploited' ]; then
        # Vulnerable and already exploited 
        echo "<result>Exploited</result>"
    else
        # On vulnerable OS, but already been secured through other means
        echo "<result>Secure</result>"
    fi
fi

[matin]

Apple just released a security update for this issue. https://support.apple.com/en-us/HT208315

[Taylor_Armstron]

Read up, matin! ;) . (released at 8:00 this AM)

[scharest]

Anybody know a way to create a Smart Group to verify if the patch was installed on systems?

[mm2270]

@scharest Per the Apple support article detailing the patch, the new OS build version will be "17B1002", so you can use the "Operating System Build" criteria to build a Smart Group that has build "17B1002" installed. That should group machines that have the patch applied.
If you want the reverse, i.e, machines running High Sierra but don't have the patch installed, use these:

Operating System Version | greater than or equal | "10.13" and Operating System Build | is not | "17B1002"

[mister2]

If anyone is looking for an link from Apple to download the security update.

https://support.apple.com/kb/DL1942?viewlocale=en_US&locale=en_US