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.
1. Run ‘Repair System Permissions‘ in Disk Utility.
Repairing system level permissions won’t solve the kext cache problem, but you’ll want to make sure they are all in order first. There is no need to repair ACL permissions for this procedure.
2. Open Terminal.app
Copy and paste the following:
sudo chown root:admin /
Hit ‘return’ and type in your admin password. This step ensures that the admin user has ownership permissions for everything on the startup disk.
3. Fix the kext cache permissions
Paste the following code into Terminal.app, hitting ‘return’ again and supplying the password if requested (if you do this shortly after step 2 you may not be asked for the password again):
sudo touch /System/Library/Extensions
4. Clear Console log and restart
The next two steps aren’t strictly necessary, but are good practice. Open Console.app, click ‘All Messages’ in the sidebar and hit the ‘Clear Display’ button in the Tool bar. Now, restart your mac.
5. Check for the problem
See if the procedure was successful by opening Console.app again, choosing ‘All messages’ in the sidebar and typing
in the filter/search bar over on the right. If you carried out the procedure above correctly, it shouldn’t return any ‘can’t create kext cache / user isn’t root’ messages since the restart time.
Featured picture: I’m not a balloon owner anymore by ~starwink