Quick Fix to Prevent dscl Unauthorized Password Changes in OS X Lion
We recently wrote about the dscl utility and how it allows a Mac OS X Lion user to change a password without knowing the existing password. The lack of required admin authentication has since been widely reported as a bug, and a small Security Update will likely be issued by Apple sometime in the near future. Nonetheless, if you’re paranoid about someone getting ahold of your Mac and changing the user password without authorization, you can manually change the permissions of the dscl utility yourself, forcing it to require administrative privileges in order to be run.
- Launch Terminal (located at /Applications/Utilities/)
- Type the following command and hit return:
- You will be asked for the current administrative password to confirm the permissions change, enter it and hit return
sudo chmod 100 /usr/bin/dscl
This is a simple permissions fix that likely mimics what an official security update will do. Using sudo chmod 100 states that only the owner (root) is able to execute the dscl command, which effectively prevents other non-admin users from accessing the directory services utility without using the sudo command, and thus the administrator password.
There may be some unintended consequences of changing those permissions, but it’s unlikely to effect most users. If you do encounter some problems you can always change the permissions back, which look to be set as 755 by default.
A big thanks to “Tjb” who left this tip in the comments!
Update: Jim T left the following recommendation in the comments, suggesting another chmod command to change the permissions:
Instead, do this:
sudo chmod go-x /usr/bin/dscl
That will -only- remove the execute permission on group and other, leaving the other permissions (read & write, and root’s full permissions) completely as was before the change. To reverse, do:
sudo chmod go+x /usr/bin/dscl
Only touch the stuff you need to touch!
His reasoning is that chmod 100 is too restrictive in that it changes the command to execute only, where as before the root user could read, write, and execute.
[…] より発見。 Lionで以前のパスワードを知らなくてもユーザーパスワードを変更できる方法がOS X Dailyに掲載されていましたので紹介します。 […]
If you do the “chmod go-x” method, what’s to stop someone from doing the following?
cp /usr/bin/dscl /tmp/
chmod a+x /tmp/dscl
/tmp/dscl
And even if you “chmod 100”, what’s to stop someone from using a copy of dscl they have on a flash drive or their web site?
Nothing.
[…] Inspired by OSXDaily […]
I set the permissions of dscl (used go-x) – after that the prefpane of the application GlimmerBlocker stopped working – always said, that the gb-proxy is not installed.
Fixed this by reenabling the permissions (go+x).
I have chomped /var/db/.AppleSetupDone too,
a easy way to become the superuser on all OsX ;)
Used chmod 700 instead, good trick until the update comes out
@ Jim T – Agreed – already set mine to: “sudo chmod -v 700 /usr/bin/dscl”.
Please please -please- do not encourage changing permissions this way using octal codes. Because right off the bat, you’re setting the root permission to 1 (execute only), whereas it was previously 7 (root can read, write, and execute), and the group/other permission to nothing, when they could previously read it. Note how when you change it back you set it to 755.
Admittedly, it’s (probably?) irrelevant in this case, but it’s a terrible habit to get into. Instead, do this:
sudo chmod go-x /usr/bin/dscl
That will -only- remove the execute permission on group and other, leaving the other permissions (read & write, and root’s full permissions) completely as was before the change. To reverse, do:
sudo chmod go+x /usr/bin/dscl
Only touch the stuff you need to touch!
As soon as you repair permissions, the old permissions are going to be restored.
If a pest already has physical access to a machine there are so many ways around passwords that it doesn’t matter if you change permissions or not. The reason this is valid is that, theoretically, some annoyer app could change a users password and lock them out of their own machine for a few minutes, which would be annoying but easily recoverable. As usual, the techno web is making a big deal out of nothing.