Directory Services Command Line (dscl) allows authenticated users to change various settings including their password. We wanted to provide some clarity to the RISK and avoid headlines, little detail or poor analysis. Below we provide all the facts along with mitigation technics to limit the effectiveness of a this type of physical access attack. It is our desire to clear up misconceptions so that users and administrators have a clear understanding of the Risk and mitigation methods to take.
Background
This issue reported by the blog Defence in Depth and than picked up by various news outlets states exactly what dscl does. (See man dscl) We think that this issue was reported without proper quantification of risk. dscl allows users to alter their setting in directory nodes they are authenticated to. (See man dscl) If you are a root user or administrator you can alter every user.
Facts
-A user authenticated in Mac OSX Lion can from the terminal use the Directory Service Command Line Utility to set various options to the directory node the user is authenticated to.
-Using the dsl command with the -passwd option a user that is already authenticated can change their password without having to provide the old password.
Last login: Tue Sep 20 07:18:30 on console
Box23Lion:~ joeuser$ dscl localhost -passwd /Search/Users/joeuser
New Password:
-This is clearly stated in the man page for dscl -passwd option:
passwd
Usage: passwd user_path [new_pasword | old_password new_pasword]
Changes a password for a user. The user must be specified by full path, not just a username. If you are authenticated to the node (either by specifying the -u and -P flags or by using the auth command when in interactive node) then you can simply specify a new password. If you are not authenticated then the user's old password must be specified. If passwords are not specified while in interactive mode, you will be prompted for them. Passing these passwords on the command line is inher-ently insecure and can cause password exposure. For better security do not provide the password as part of the command and you will be securely prompted.
-As an account with Mac OSX Administrator or as root privileges you will be able to change any user's password. This is why you should never do general computing as the root user.
-The original Key Chain cannot be accessed without the old password, thus your saved passwords are protected.
-The File Vault Recovery Key and Password will continue to work.
Myths
Myth-You can change any users password and lock them out of the system.
If the malicious actor has physical access to a logged in account with Administrative privileges they can make it difficult for a user to gain access. Any password change will not affect the users keychain which stores saved passwords and developer certificates, the old password is required to access that key chain. They will not have access to chainging FileVault Settings.
Using an Administrator account for computing is extremely bad idea, MacOSX is Unix thus privileges come with responsibilities. Create a general account that for doing your daily computing task. If the Administrator password is changed resetting it is an easy task.
Myth-A general user can change any password they want.
One hundred percent false, as a non-administrative user cannot change the password of any user other than themselves. Read the man page above.
Box23Lion:~ joeuser$ dscl localhost -passwd /Search/Users/aliceuser
New Password:
Permission denied. Please enter user's old password:
passwd: DS error: eDSAuthFailed
<dscl_cmd> DS Error: -14090 (eDSAuthFailed)
Myth-I can be locked out of my system.
If a malicious actor gains physical access to a command prompt with root or Administrative privileges and changes the user or root account all is not lost. You can use your Lion Emergency Disk or Lion Recovery Disk Assistant.
Primary Mitigation
Never do computing as the Administrator, set up an Administrator account and a user account. Do all your computing as the user. Mac OSX has various layers of protection, use them. Shame on any organization or user who continues to operate in this manner or falsely confuse users instead of educate.
Secondary Mitigation
In System Prefences>Security & Privacy ensure that "Require Password immediately after sleep.." is selected.
In System Prefences>Security & Privacy ensure that "Log out after 2 minutes of inactivity" is selected.
For organizations with multiple administrators, never give your administrators the keys to the castle. Have specific administrative accounts that are logged and audited.
Make sure to setup File Vault and to store your recovery key in a safe place.
RISK
The risk of this type of attack is LOW due to the need for the attacker to have physical access and administrative privileges.
We believe that already poorly configure MacOSX machines will be vulnerable to this and a host of physical attacks.
Disappointment
We are disappointed that there continues to be an issue with dscl, which has been reported to Apple in the past. The user should be prompted again to enter their password even if they are already authenticate to the node. At that same time there is no weakness or true flaw, just bad implementation. We also think that the combined layers of protections in Mac OSX mitigate this risk, similar to all physical threats. So the real Risk we rate as LOW.
There is nothing to discover or new here except that someone read the man page for dscl who may have not done before. Due to the limited understanding about how best to secure MacOSX a LOW RISK flaw has become poorly reported on and explained.
We expect better and have done so here.
Tuesday, October 11, 2011 at 04:43PM 
