FileVault 2 uses the GeneratedUID user attribute to save who is permitted to unlock an encrypted volume. If the GeneratedUID of a user differs from what was generated (or pulled from LDAP) when FileVault 2 was enabled, the user will not be permitted to unlock the machine, as their account will appear to be unavailable at the EFI menu. Also, this causes the crash of System Preferences on their Mac whenever they try to access the Security & Privacy prefpane.
This problem arises when /usr/bin/mcxrefresh runs and pulls a null value or a value different than what is stored locally from LDAP (if the attribute isn't defined for the user in question or is defined incorrectly, respectively), overwriting the GeneratedUID stored locally (which is generated and only stored locally when FileVault 2 is enabled without a matching LDAP attribute).
In other words, if an apple-generateduid value exists in LDAP for a user and is mapped properly on the users Mac to the GeneratedUID attribute, FileVault 2 will not generate a new value, but will instead use the value stored in LDAP.
I was able to resolve this issue by adding an attribute called apple-generateduid to the LDAP entry of any user experiencing this issue. I could generate a random value for this attribute in Python by running the following one-liner from my terminal:
python -c 'import uuid; print str(uuid.uuid4()).upper();'
This isn't the only step, however. You must also add a mapping for this attribute on the client side. This is easily done using the following steps:
- Open System Preferences.
- Click Users & Groups.
- Click Login Options.
- Click on the Unlock Icon.
- Under Network Account Server, click Edit.
- Click to highlight your directory server.
- Under Services, double-click on your directory service (in my case, it was LDAPv3)
- In the window that slides open, highlight your configuration name, and then click the Edit... button.
- Under Search & Mappings scroll down and single-click on Users to highlight it.
- Click the Add button (the left one).
- Choose GeneratedUID from the list of available Attribute Types.
- In the right column, click the Add button, and type
apple-generateduid. Click OK to save the changes until you're back at the main System Preferences dialog.
- At this point a mapping from GeneratedUID to
apple-generateduid has been created. Now when OS X looks up the GeneratedUID value it will get the value of apple-generateduid from the user in questions LDAP entry.
Finally, it's important that the locally stored value of GeneratedUID and value stored on LDAP match. Run the following command and make sure the two GeneratedUID values match:
dscl /Search search /Users GeneratedUID $(dscl . read /Users/$(echo $USER) GeneratedUID | cut -d " " -f2)
You aren't carrying forward your shell environment into the su adm session. so if you echo $PATH in the usracc account and the adm account, you'll find that they aren't equal (which is why adm can't find the updatedb command). All you need to do is tell su that you want to carry forward your env (su -m adm should do it) or just add the path to updatedb.
Though on my box updatedb is called /usr/libexec/locate.updatedb and is a script.
Best Answer
Patch available, click here, or just update on the machine
Interestingly enough there is no patch for the beta and developer versions of OSX yet as far as I know. I'll update this answer as soon as I hear of them.
Download the patch above. Leaving the rest of the post for history :-)
The CVE is CVE-2017-13872 and NIST will update the analysis in the near future.
Original answer, relevant without patch
First off, do not disable the root account via the GUI, having a "disabled" root account is the cause of the problem.
You shall enable the root user and give it a password. This is important, since the vulnerability is available remotely as well, via VNC and Apple Remote Desktop (to name a few)(another source).
There are two basic ways to do this; GUI and terminal.
First off, GUI
To enable the root account, go to "Directory Utility", ie cmd + space and search. Press the lock to unlock "admin mode", then enable the root account through edit -> "Enable Root User".
It should ask for a root password, for now enter your normal password (so you don't forget it). If it doesn't ask for a password, use Edit -> "Change Root Password..." above.
Terminal
If you are more of a terminal person, use the below:
This is enough with a terminal, the problem with the GUI way is that we have to enable the account to set a password, which we don't have to with the terminal.
Notes
Even if you have a password set for the root account your computer it will become vulnerable if you disable the root account. The action of disabling the root account seems to be the culprit. So I repeat, the root user should be enabled and have a password if using the GUI, whilst via terminal only using ´passwd´ is "ok" (although this state is unreachable via only the GUI). It seems that the "Disable Root User" in "Directory Utility" removes the password for the root account, in a sense giving you a password-less root account which is vulnerable.
It seems like trying to log in with "root" in a systems login-window enables the root account if it is disabled previously. Ie with a disabled root account you need to enter root twice in a systems login-windows to gain root access, and (according to my testing) on the first try the root account is enabled (with no password if not set via
passwd), and on the second try you go through.It seems that the issue has been in the open since at least 2017-11-13 (13th of November), when it is mentioned in the Apple support forum.
Please prove me wrong, I would really appreciate to be wrong right now.
Scary update
After enabling the passwordless root account (i.e. through the system preferences panel and clicking a "lock" and entering "root" with blank password one, two or three times (number of times depends on initial state)) it is possible to log on to the computer from the main login screen using "root" and a blank password (!). SSH / Telnet does not seem to work, but Apple Remote Desktop, Screen Sharing and VNC are vulnerable.
So for networks admins it might be of interest to temporarily drop packets to the following ports:
Additional reading:
A valiant attempt to reference other sources dealing with the issue. Do edit and update my answer if you have more.