@kentmj wrote:

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

This. :)

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

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

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

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

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

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

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

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.

But the fix only applies to 10.13.1.

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.

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.

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

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

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

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

Source 1, Source 2

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?

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.

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

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

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.

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

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

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

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