Vulnerability 10.13 - Root

rderewianko
Valued Contributor II

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.

82 REPLIES 82

donmontalvo
Esteemed Contributor III

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

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

@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

--
https://donmontalvo.com

geoffrepoli
Contributor

@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
New Contributor III

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

kcranford
New Contributor II

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
New Contributor III

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

charlesteese-mf
New Contributor II

@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
New Contributor III

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
Contributor

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?

44f80daae2a34996bc1a94cc8e6dd7ef

jrwilcox
Contributor

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

charlesteese-mf
New Contributor II

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

donmontalvo
Esteemed Contributor III

@kentmj wrote:

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

This. :)

--
https://donmontalvo.com

rderewianko
Valued Contributor II

@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
Esteemed Contributor III

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

--
https://donmontalvo.com

rderewianko
Valued Contributor II

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

gersteina1
New Contributor III

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
Contributor
Contributor

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

john_sherrod
Contributor II

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

MandyDroid
New Contributor II

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

jhuls
Contributor III

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
New Contributor III

But the fix only applies to 10.13.1.

mm2270
Legendary Contributor III

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
Valued Contributor

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
New Contributor III

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

keaton
Contributor
Contributor

@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
New Contributor III

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

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

Source 1, Source 2

abtsux
New Contributor

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
Valued Contributor III

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
Legendary Contributor III

@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
Valued Contributor III

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

jedi1yoda1
New Contributor III

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
Valued Contributor III

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

kquan
Contributor

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
Contributor

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
New Contributor III

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

Taylor_Armstron
Valued Contributor

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

scharest
New Contributor II

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

mm2270
Legendary Contributor III

@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
New Contributor II

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