Blog Archives

yes, enable the root user if you’re on High Sierra


Update: There’s a security update available in the App Store now that mitigates this risk. It should be applied by all High Sierra users as a matter of urgency.

Today has been all about a monumental security flaw in High Sierra which allows anyone to log in to a mac and immediately become the root user without a password at all.

If you haven’t yet seen the news, check out the 30-second video above. If you’re not on High Sierra, no need to worry.

Although there are conflicting reports of exactly under what conditions the exploit can be triggered, it seems that in most cases two attempts are required to escalate user privileges. The first time enables the root user with the password that you do or do not put in the password field (i.e., it’ll accept a blank password). The second time is using those credentials to unlock whatever it is you want to unlock (in the video, only 1 attempt is shown as I had already ran the exploit once prior to making the video). There also seems to be conflicting reports about whether the flaw can be exploited remotely. What does seem certain is that malicious 3rd party applications could programmatically use it to escalate privileges for themselves, so it’s important to make sure you take the proper precautions to deal with this flaw until Apple patches it with an update.

Alas, with so much excitement, it seems some people are getting confused about exactly what needs to be done to avoid falling victim to this security flaw. The answer is not, as has been mistakenly suggested in some quarters, to disable the root user, but quite the reverse: you need to enable it.

The one thing that stops the flaw from being exploited is having the root user already enabled and set with a strong password.

By default, macOS ships with the root user disabled, so unless you (or someone who administrates your mac) has enabled it at some point, it won’t be set. If you’re not sure, this AppleScript will quickly tell you the status of the root user:


Update: further testing on 10.13 shows that the root user may be enabled without writing a ShadowHash entry to dscl. In that case, the script would incorrectly indicate root was disabled. Thus, to be certain, the best way to check is to follow the instructions in the apple support article linked to below.

If you find the root user is disabled, then go and enable it by following Apple’s instructions here:

Be sure to use a strong password of at least 14 characters or more. You can save the password if you want, but it doesn’t really matter much if you forget it. There’s really never any need for an admin user to require the root user at all, and there are other ways to get root privileges safely through the Terminal if needs be.

how to: check for Sparkle vulnerability

Screen Shot 2016-02-12 at 15.32.18

[updated Mon 15th:]

Here’s what we know about the widely-reported vulnerability found in Sparkle so far:

1. It requires a version of Sparkle earlier than 1.13
2.1 It requires the SUFeedURL address to be an unencrypted http address AND/OR
2.2 the release notes address to be an unencrypted http address.

Condition 1 and one (or more) of conditions 2 need to be true to make the exploit possible. You can check to see if condition 2.1 is true for many apps on your system with the following procedure:

1. Control-click on the app in the Finder
2. Choose ‘Show Package Contents’
3. Navigate to /Contents/Info.plist
4. Hit the space bar to open in quick look, scroll down for the SUFeedURL field (it won’t have one if it doesn’t use Sparkle). The field will show you whether the address is https or not.

To make life easier, you can run this script in the AppleScript Editor (/Applications/Utilites/Script to do the job for you.

#script version 1.64
#regression to 1.52 and then
#added: now includes apps that do not have SUFeedURL key in plist and reports their Sparkle version number
#added: borrowed Bill Cheeseman's idea of using choose list and offering to launch the app
#added: borrowed reverse_offset handler from Nigel Garvey's post on MacScripter
#changed: test if Sparkle is < 1.13.1 first
#shows the Sparkle version number for each entry in the list
#added logic for opening prefPanes if chosen from the list
#changed the mdfind command to improve speed
#searches for keys of the form "SUFeedURL*" rather than just "SUFeedURL"

on extractSUFeedURL(aRecord)

set aRec to "httpx"
set aRec to item 1 of aRecord
on error errorMessage
set aRec to errorMessage
set aRec to my parseErrorMsg(aRec)
end try

return aRec

end extractSUFeedURL

on parseErrorMsg(aErr)

set what to "SUFeedURL" --define the full or partial record name you're trying to find
if aErr contains what then
set theStart to offset of what in aErr
set thisString to text theStart thru -1 of aErr
set theEnd to offset of "," in thisString
set subString to text 1 thru theEnd of thisString
--log subString --see the record name and its value in Script Editor's Messages pane
return subString
end if
end parseErrorMsg

on reverse_offset(d, t)
set astid to AppleScript's text item delimiters
set AppleScript's text item delimiters to d
set ro to (count t) - (count text item -1 of t)
set AppleScript's text item delimiters to astid
return ro
end reverse_offset

set foundCounter to 0
set infoFilePath to "/Contents/info.plist"

set theApps to do shell script "mdfind \"kMDItemFSName == '*.prefPane'cd || kMDItemFSName == '*.app'cd'\""
set theApps to paragraphs of theApps
set sparkleAppsList to {}

tell application "System Events"
repeat with anApp in theApps
set anApp to anApp as text
set aFrameWork to anApp & "/Contents/Frameworks/Sparkle.framework"

if exists disk item aFrameWork then
--get Sparkle Version first
set aSparklePlist to aFrameWork & "/Versions/A/Resources/Info.plist"
set thePlist to contents of property list file aSparklePlist
set theValue to value of thePlist
set sparkleVersion to CFBundleShortVersionString of theValue as text
on error
set sparkleVersion to CFBundleVersion of theValue as text
end try
end try
-- compare version num
considering numeric strings
set vulnerable to sparkleVersion < "1.13.1"
end considering
if vulnerable then
--get SUFeedURL if it exists
set thePlist to contents of property list file (anApp & infoFilePath)
set theValue to value of thePlist

set thisSUFeedURL to my extractSUFeedURL(theValue)
if length of thisSUFeedURL = 0 then

set thisSUFeedURL to "httpx"
end if
on error
set thisSUFeedURL to "httpx"
end try

if thisSUFeedURL contains "http:" then
set end of sparkleAppsList to anApp & " : uses insecure update URL (not https) " & "with Sparkle v" & sparkleVersion
set foundCounter to foundCounter + 1
else if thisSUFeedURL contains "httpx" then

set end of sparkleAppsList to anApp & " : update URL unknown (http/https??); uses Sparkle v" & sparkleVersion & linefeed & linefeed
set foundCounter to foundCounter + 1

end if

end if
end if
end repeat
end tell

set thePrompt to "Found " & foundCounter & " items that may be using a vulnerable form of the Sparkle framework: " & linefeed & linefeed

choose from list sparkleAppsList with title "Sparkle Vulnerability Check" with prompt thePrompt OK button name "Launch"

if result is not false then
set appPath to item 1 of result
get offset of " :" in appPath
set appPath to text 1 thru (result - 1) of appPath
set ro to reverse_offset("/", appPath)
set appPath to text (ro + 1) thru -1 of appPath
if appPath contains "prefPane" then
set paneOffset to offset of "." in appPath
set paneName to text 1 thru (paneOffset - 1) of appPath
log paneName
tell application "System Preferences"
reveal (first pane whose name is paneName)
end try
end tell
tell me to launch application appPath
end if
end if


However, be aware that this script will not find certain plug-ins (e.g., Mail plug-ins that use Sparkle).

If the app runs on 10.6, it’s not possible for Sparkle to be updated to the latest secure version, 1.13.1, so you need to check with the developers that they’re using https addresses for both the appcast feed and the release notes html.

Rest assured that Sqwarq apps that use Sparkle (App Fixer, DetectX, FastTasks 2, and OSXClock) all use encrypted https update feeds and release notes addresses, so as far as we’re aware at the moment, none of our apps are vulnerable to the exploit regardless of what version of Sparkle they’re using.

As said above, we’ll update this post if things change as the story unfolds.

Credits: Thanks to Yvan for significantly improving my earlier drafts of the AppleScript and writing the code for retrieving the Sparkle bundle number. Thanks to Chris Stone for tweaking and eeking a bit more speed out of the mdfind command. Thanks to Al for pointing out that in earlier versions of the script the Display Dialog message could get truncated.

%d bloggers like this: