Comments
jbtule • September 27, 2011 7:45 AM
Dumb mistakes by apple, dumb mistakes in reporting or both? From the article comments it looks like both, it looks like most of what is suggested in the article is not reproducible.
elgringito • September 27, 2011 8:26 AM
Apple probably makes some dumb mistakes, as everybody does. But on this very specific point, it seems to me that the author of the blog post did not go all the way to illegitimately changing a user password. Following the method suggested by the post, you end up typing
$ dscl localhost -passwd /Search/Users/bob
At this point you are indeed asked to enter a new password. Yet, if you do, you are then asked to enter the original password. If you fail to do so, the original password is not changed.
Granted: one would expect the questions the other way around.
Bottom line: as far as I can tell, the blog post is wrong.
wiredog • September 27, 2011 9:07 AM
Doesn’t the attack only work if the user is using an account with root privileges? If so, the fix is to not do that, which is, IIRC, the default for OSX. Also the default for Windows, Linux, and *BSD.
Clive Robinson • September 27, 2011 9:42 AM
If you look at the comments on the pages linked to you will see that the issue is not clearly understood.
The changing of the password without chalenge is for only of the currently logged in user (“bob” in the case of the article so the dscl command needs changing appropriately).
Thus many think incorrectly that all it could be used for was locking a user out.
However OS X uses “sudo” so if the current user is also in the sudo-users file then changing the password should enable the attacker to get root priveledge etc and do a sushi style attack etc to maintain the privilege escalation (depends on how well sudo has been setup).
Even if sudo has been set up correctly to stop simple attacks as copying the command shell program some command line programs have “shell escapes” such as editors etc. Thus if you are alowed to use such a program by sudo you can escape out to a root shell…
These sorts of Unix comand line attacks are more than 20years old so maybe to “old skol” for many modern attackers…
Michael • September 27, 2011 9:48 AM
@jbtule: Don’t forget dumb mistakes by commenters attempting to reproduce the behavior.
RH • September 27, 2011 10:09 AM
This is something that has bothered me about Apple for some time. They seem to have the attitude of “we’re built on BSD now, so we’re secure.” Anyone remember the root escalation attack in an earlier version of OSX with the stringent requirement of “attacker must have an open window to click on?”
man sudo • September 27, 2011 10:10 AM
DESCRIPTION
sudo allows a permitted user to execute a command as
the superuser or another user, as specified in the
sudoers file. The real and effective uid and gid are
set to match those of the target user as specified in
the passwd file and the group vector is initialized
based on the group file (unless the -P option was
specified). If the invoking user is root or if the
target user is the same as the invoking user, no pass‐
word is required. Otherwise, sudo requires that users
authenticate themselves with a password by default
(NOTE: in the default configuration this is the user’s
password, not the root password). Once a user has
been authenticated, a timestamp is updated and the
user may then use sudo without a password for a short
period of time (15 minutes unless overridden in sudo‐
ers).
alfora • September 27, 2011 11:38 AM
I can confirm what elgringito said:
“At this point you are indeed asked to enter a new password. Yet, if you do, you are then asked to enter the original password. If you fail to do so, the original password is not changed.”
This is what happens on my Mac when I try to change the password of another user with this method:
alfora$ dscl localhost -passwd /Search/Users/otherUseronMyMac
New Password:
Permission denied. Please enter user’s old password:
Paul • September 27, 2011 12:01 PM
@alfora:
This is what happens on my Mac when I try to change the password of another user with this method:
What happens if you try to change YOUR OWN password with this method? Being able to change another user’s password isn’t that interesting since most Mac’s are desktop computers and Desktop’s generally just have 1 or 2 users who all have sudo access.
If you can change your own password without being prompted, so can a script, malicious java applet, etc. Someone sends you an e-mail with a .dmg file for a program “you have to try” and it copies your shadow file, changes your password, gets root, makes a new account for itself, and restores your shadow file.
Remember, there are TWO attacks here: the shadow files being exposed, and (potentially) changing a users password. Can you confirm if it prompts when you run the command on your own account?
hum ho • September 27, 2011 1:27 PM
Its not a mistake on Apples part, it works as designed (makes it easier to take over someones account, eg. by law enforcement)
chris • September 27, 2011 2:48 PM
I have just tried this on a fresh install of 10.7.1, and it did in fact work.
I was able to get a co-worker whose computer had a password that I did not know and change it, then run a command with sudo using the new password.
This really shows again that giving users root access to the system by default, through sudo or other means, is a bad idea.
chris • September 27, 2011 3:19 PM
I would also like to add that to make the command even more user-friendly you can instead do
$dscl localhost -passwd /Search/Users/`whoami`
sopublic • September 27, 2011 4:34 PM
Hi, there is nothing new. If you are on a Mac as the ADMIN user you have the privileges to change any users password. That is why you should never be root or admin when using MAC OS as should be the case with any system.
IF you are a general user you can change you password, you cannot change the password of another user. You will not have access to the keychain or the encrypted disk.
I think this is a case of people not reading the MAN page for dscl, so nothing new, we can just read.
Our take. http://mcaf.ee/3h8mg
Man Page for dscl which you should read for the facts in this. http://mcaf.ee/qm1e8
Here is the passwd option- section….
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 inherently inse-
cure and can cause password exposure. For better security do not provide the password as part of the
command and you will be securely prompted.
So, security 101, know thy system…
Clive Robinson • September 28, 2011 3:00 AM
@ sopublic,
“Man Page for dscl which you should read for the facts in this”
So the fact that the dscl program allows some one of ill intent to either foist a rouge script on a user or go upto a mac keyboard and perform a very very easy privilege escalation is OK because it’s
“a case of people not reading the MAN page”?
Talking about ‘not doing this’ or ‘not doing that and “security 101” to the average user (especialy the average Mac user I’ve met) is ridiculous. Most I’ve met have difficult with the concepts behind why you should have a screen saver password.
Much of the trouble revolves around “the nice man in the” advert / shop / security forum “said macs are safer to use…”
Not forcing an ordinary user to correctly authenticate any action that involves the security of their account or the system they are using is a bad idea and has been known to be a bad idea since the early days of operating systems nearly half a century ago.
Look at it another way, it’s the same reasoning as not puting sheath or flick knives in your toddlers play pen.
NZ • September 28, 2011 4:00 AM
@ sopublic
How can Macs have man pages if they don’t have a file system?
P.S. You must provide current password to change it on NT.
RolandYoung • September 28, 2011 6:58 AM
@ sopublic – You have missed the point. This is something new. The man page you quote says “If you are not authenticated then the user’s old password must be specified”. In this context, “authenticated” means that you have shown dscl that you know the password for the account. The bug that is being discussed here is that the dscl command in OS X Lion now allows you to change your own password without being authenticated in this way.
alfora • September 28, 2011 2:06 PM
@Paul: You are right. If I do
alfora$ dscl localhost -passwd /Search/Users/alfora
it just asks me for a new password and lets me change it.
Dirk Praet • September 28, 2011 7:11 PM
I have to agree with Clive. One of the things Apple as a corporation should be really careful about is not to let form and appearance prevail over content. History has shown that to be the undoing of many people and enterprises alike.
alt-bob • September 28, 2011 8:50 PM
@NZ
Why would you think Macs don’t have file systems?
Mac != iPad
And even iOS devices have file-systems, it’s just not exposed for user interaction.
brett • September 28, 2011 9:57 PM
So the fact that the dscl program allows some one of ill intent to either foist a rouge script on a user
wonders what a rouge script might to do a user, and whether a lipstick script would be worse
NZ • September 29, 2011 2:46 AM
@alt-bob
It is a very old joke: “What filesystem do Macs use? – Mac user doesn’t need to know that his computer has a filesytem.”
sopublic • September 29, 2011 8:01 AM
@Paul.
You are authenticated to the node as it says in the man page when you log in. Is dscl a poorly implemented program, yes, but if what is described is in the man page how is that new unless people do not understand how MAC OSX works. The points of authentication…
Think about sudo, when you get authenticated to that command you do not always have to resubmit your password for a set time.
Some major points to consider, I suggest you read the complete -passwd option. I provided it below because you are missing an import detail, that being you are authenticate to the node. When you log into MAC OSX you are authenticated as that user to the node. So, you are authenticated to the system. This open up a physical attack vector, I argue that other defenses minimize the risk. There is residual risk of physical attack, but very small.
- You cannot change another users passwords without that users password unless you are admin. If you are doing computing as root or admin than you have bigger security issues. Does not matter the system.
- If an physical attacker changes the user password he cannot access the old keychain without the old password. The physical attacker cannot access the encrypted disk as well. They will be prompted once the password is changed if they try to access either.
- If you read the man page for the command it states what it does, so this is not new since it is in the man page. I am somewhat of a old school unix dude so I tend to read the man page of any command so I know what it does. I am surprised the reading level of most admin, it is a problem. They tend to miss words and more often than not if they do not understand a word or context they will not look it up.
So, read then man page again, read and understand what each point means and than you may understand why I think this is not new. Is there risk, yes but not walls come down we need to panic risk. In- fact we should say, we are happy, someone found a issue by reading a man page that has been there for a long time. The integration of dscl into the OS creates some risk and it should be corrected. In the meantime risk super low, use other protects in conduction to mitigate it. Residual risk remains but it can be managed. Maybe with some simple old school unix voodoo. 🙂
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. <b> 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. </b> 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 inherently inse-
cure and can cause password exposure. For better security do not provide the password as part of the
command and you will be securely prompted.
Sopublic • September 29, 2011 4:00 PM
@alfora.
You are changing your password, yes it will work, bcause you are logged in to the node at log in. If you are an admin user you can change them all, after all who works as root? If you do you have bigger security issues.
Try as a regular user to change another users password, no dice.
After you change your password, log out and log back in what happens? Do you need your old password?
Know thy os… Mac have issues just like any system. We need clear explainations with all the facts, risk, residual risk, threats and possible impacts. otherwise we create a environment that is guessing about security.
People in the security field have to be like Joe Friday, just the facts….
Wzrd1 • September 30, 2011 10:26 PM
So, Apple breaking the hell out of *BSD has finally caught up with them.
Just for the record, this is actually ANCIENT news, which was recently caught onto by the media. As I recall, Apple sent out a patch for it.
The fact of the matter is, Apple made a dumbest of the dumbest of mistakes and they got caught at it. I’ve fired people for far, far, far less.
NZ, I’m on my MacBook Pro, I know it has a filesystem. It’s running Apple’s excuse for a high performance system, with journaling. I also use a SunOs workstation, Windows workstation, Linux workstation and *BSD workstation. Each, to its dedicated purpose.
As I’m well aware that Apple broke the security of *BSD, I take commonsense measures to prevent a hostile script from running, to include rejecting html mail at my mail server.
Of course, I’m also an information security professional with a 4 year track record of keeping a US military installation malware free, even when the REST of the theater was infected by a worm. My “secret” is following best business practices, keeping users informed of threats, keeping current with emerging threats and compensating for them and ensuring management knows what is going on, to ensure their continued buy in on information security.
ROI • October 9, 2011 5:08 PM
I recently bought a used iMac of 2009 vintage. It has two accounts, and it is WAY behind in Software Updates.
How can I change the password of the Admin and User accounts so I can wipe the
drive and start over? EVERY DISK I’VE TRIED TO USE, WITH INTERNET INSTRUCTIONS FOR PW CHANGE ALL REQUIRE A PASSWORD OR I NEVER MAKE IT TO THE PROMISED WINDOW WHICH IS SUPPOSED TO ALLOW ME TO CHANGE THE PASSWORD.
This thing has 10.5.8 and I’ve used 10.6 disks and still cannot do a ‘new install’ without a password.
Needless to say, the original disks, and the former owner are not available. One disadvantage of buying from a Pawn Shop!
I originally wanted to see what software was available in the locked account, so I would not erase Photoshop or something else nice to have. Now, all I want to do is to wipe things clean and start over.
At present, I have the gray disks for 10.6.2 and 10.4.10, plus a black disk marked “Mac OS X Leopard CPU Drop-in DVD”. They all produce strange results and none follow the password change ‘wisdom’ found on the internet.
Suggestions would be appreciated.
ROI – w8roi@wowway.com
me • December 9, 2011 12:33 PM
Gee, where did all the Apple experts go?
@ROI, I’m not an Apple expert but “…all the disks I’ve tried to use…” might be part of the problem. I don’t know what you may have tried so far in desperation or if you fixed the issue, but I hear that the Apple platform can be pretty finicky about thisVersion before thatVersion being loaded. IOW, don’t try to jump ahead necessarily. Work with the earliest, compatible version first ( read: get that working before worrying about updating it ).
You didn’t mention anything you do see, only what you can’t see. For my part, I find troubleshooting that much more difficult if everything is explained as kind of one big ‘blank’ by the poor person trying to get something reasonable done.
Sounds stupid maybe, but have you run a search for any ‘default’ passwords on the o/s’s/disks you have? Can you get to a terminal window and do some of the ‘sudo’ magic, ( or bad thing, as some take it to be ), in order to bypass those accounts?
Also, can the originator of the disks maybe help you out ( assuming someone loaned/gave them to you )?
If you can’t wipe the drive ‘clean’, what do you see on it now?
If this has been helpful, please send a check of $19.95 + $3.00 S&H to: NoClue Corporation, LLC, someCity;someState;0110001
1-800-oops-tralala
If it hasn’t been helpful, do the same. 🙂
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Clive Robinson • September 27, 2011 7:42 AM
It is not just passwords that Apple are having security problems with.
And as noted many of the problems fall in “classes of known problems” so they cannot say it’s something new or unexpected.
Also Apple are started to be slated for their tardy response to critical security faults (such as the keyring issue with EVSSL certs from DigiNotar).
Apple realy need to “up their game” their modifications to the underlying OS security model to “aid usability” just are not acceptable.
I’m fully expecting their various OS’s to rise rapidly to the top of least secure OS when normalised against market share.
The old advice about “By a Mac as they are more secure than MS Windows” is now shown up for the lie it’s always been.