Related link: http://securityfocus.com/archive/1/367116/2004-06-24/2004-06-30/0
Came across this posting on BugTraq. Apparently, swap files in Mac OS X (as of 10.3.4) contain user passwords in clear text.
Run the following on your Mac OS X box to see if you can find your passwords stored in clear text:
sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname
At first, this ‘vulnerability’ may not seem like such a big deal. After all, the swap files are only readable by root. However, a system administrator should not have it so easy if he or she would want to obtain user passwords. Passwords should never be stored in clear text _anywhere_. A malicious trojan with root privileges can now steal user password in clear text, and many users use same passwords for other accounts, so this is a big deal. In addition, Keychain passwords are also apparently stored in clear text within the swap files (I haven’t tested this). I hope Apple fixes this soon!


???
This didn't work for me. No passwords at all.
Didn't find my password
I replaced longname with my longname surrounded by double quotes. I found several instances of my username, but no cleartext password.
Doug
tried other combinations, no luck
I also tried using the command verbatim. I also used \ to indicate a space in my long name.
No clear text password.
Doug
works when searched on password
I found 2 instances of my cleartext password. but i think these entries are related to other applications than Apple's own. Going to try it today on a fresh install. Grepping on your password comes up with the entries if they are there.
Doesn't seem to happen on my PowerBook
I've looked through all my swapfiles using that grep command, and although my user name shows up a number of times, followed by the word "password", my actual password does not appear anywhere.
I wonder what the difference is? I am also running OS X 10.3.4:
%uname -a
Darwin Alacrity.local 7.4.0 Darwin Kernel Version 7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu-517.7.7.obj~7/RELEASE_PPC Power Macintosh powerpc
Of course...
Your password will have to have been swapped out for this to work. There's always the possibility that it just hasn't been swapped out yet.
Pull out all except 128MB of RAM and try again :-)
Yep! It works for me. . . .
There it is, my password in plain text after running the command. Not good.
yep, worked for me
Sure enough there was my password in plain text. This is not good. Hope Apple jumps on this.
dammit
Okay - that worked on one machine, and it returned an odd string that I don't know about, so I'm going to presume I've been rooted.
What would be the best next-step (now that we're panicking?) Formatting, fresh-installing are clear, but there're alot of preferences in the system; can I keep 'em? Also, is my keychain compromised? Do I have to start from scratch?
Nothing new and not just Macs
This is not new and it is not just a Mac problem. This is why so many passwords, credit card numbers, etc. are found on old hard drives. The same thing happens in Windows, Unix, and any other operating system that uses virtual memory. The only problem is Macs so brilliant ideas to store passwords in a an appication so that they can be swapped to a disk although ssh and pgp/gpg key agents have a simular program. Also note that anything you type into a browser might also be swapped to the disk. If you have typed passwords, SSNs, credit card numbers into a site such as Ebay, then you need to assume that those numbers are stored on your hard disk. The only solution is to prevent trojans/crackers etc. out of your system and to make sure to wipe your disks clean before you ever discard them. Most people think that a reformat will distroy this information. The only way to insure that it is gone is to write over each sector specifically. Preferably several times using different data patterns, ie, all zeros and all ones.
[followup]Nothing new and not just Macs
It is of course possible to turn swapping off. At least it is under Linux: swapoff -a. That may not however be such a good thing either. There was some debate about this in lkml some time ago.
Not a problem here
My system has been up and running for weeks (I can't imagine that everything has not been swapped out at one time or another). And there are a couple of entries that show up but none has my password.
What was the source of UserName and password that you saw? Was it a logon to an AFP share? Some web site name/password? or your initial log on? I know there are times when servers will not accept encrypted passwords that OS X will send them in the clear? Maybe that is your case?
Give us more info, so we can figure out what, if anything, is vulnerable?
Nothing new and not just Macs
Applications or binaries that work with passwords have the ability to use appropriate API to lock memory space holding sensitive data (as the BugTraq post says, one solution is to use mlock()) , so it is possible to prevent this. I don't care if it is not just a Mac problem, every operating system vendor should attempt to fix this. Apple is now one of them, and I hope they do something soon.
A Joke?
>>> However, a system administrator should not have it so easy if he or she would want to obtain user passwords.
You're kidding right? As root, I could copy your entire user directory to a new user and view all your files as that user and you would never know.
What exactly would a root user need your password for?
More importantly, wouldn't same admin have set your password to begin with?
A Joke?
You(root) could copy my directory or my files or delete my account or do whatever you want. But an Operating System should not allow you(root) to view my plain text password so easily.
An administrator may set my initial password, but I can change it. Infact if you are a good administrator, you should recommend that users change their password the first time they log on.
I am NOT saying that root cannot do anything he or she wants. I am suggesting that an Operating System should attempt its best to not store passwords in clear text to make it so easy for root or anyone else to obtain your plain text passsword. That is the whole point behind /etc/shadow, and the reason Operating Systems these days do not store user passwords in clear text. Here's another way of thinking about it: if root can obtain user passwords in clear text anyways, what is the point of /etc/shadow? Why not just create an /etc/shadow that is readable by root and store user passwords in clear text there?
Nothing new and not just Macs
mlock() is only partially applicable. It does not prevent memory from being written to the disk during suspend for instanstance. While it can prevent the programs data from being swapped it does not nessessary prevent the entire programs memory, with stack, from being swapped.
The only way that I know around this problem is to
a. keep your system secure through other means
b. turn off swapping entirely
c. on Linux you can prevent a program from being swapped buy setting it suid which comes with other potential problems.
Root can get the password without looking for passwords saved on the disk. False getty logins for instance.
A Joke?
If I am root I can create false logins redirect web traffic to false sites etc. I do not need direct access to your password. It is an old recommendation to use a false id-password on your first login attempt to *help* prevent this kind of problem.
If you cannot trust the system administrator then do not use his/her system. Definitly do not use the same id-password that you use for other things.
/etc/shadow is around because some applications rely on the historical mistake of leaving /etc/passwd world readable. While the passwords are hashed, having the hashes along with the method and salt used to derive them makes it easier to brute force the passwords on a different system.
A Joke?
Today's larger organizations often have more than one computer. Sometimes, a user will make their password the same on one system as it is on another. "One sign-on" or "Single sign-on" solutions contribute to this phenomenon.
So, while if focused on a single system, you have a point. If the scope of an attack and penetration effort encompasses more than that, then it could be the thread that unravels the entire sweater.
That's beside the point, however. If there's a hole, it should be plugged.
Nothing new and not just Macs
Are passwords the only thing that you wish to mlock()? Should your browser be protected to prevent your credit card numbers from being written? What next. Your word processor because some of the files are encrypted with your passphrase or key? Will there be anything left that can be swapped out to conserve system resources?
A Joke?
Having the hashes along with the salt makes it more difficult to brute force the passwords. This is the whole purpose behind salts. Without a salt, I can just create a catalog of all possible combinations of the password, and store the hash of each, and just compared the hashes with the hash in the password file to find passwords in O(1) time.
Yes, root can obtain your real password if he or she tries to. But it shouldnt be _this_ easy. If root had to install trojans or sniff the traffic to obtain a local user's password (yes I know root does not need a local user password to do anything on the host, but may want to steal it because users in reality do use same passwords for multiple accounts), this would discourage an administrator in a large organization. This also introduces liability. As an administrator, I don't want to be able to see user password in clear text this easily.
If a host were to be compromised, there is some comfort in knowing that strong password hashes stored in /etc/shadow may take a while to be cracked. With a vulnerability like this, if your system is compromised, clear text passwords of users will compromised as well, without any need for the intruder to brute force them.
My opinion is that passwords should never be stored in clear text anywhere, it is just good practice.
What process is the password being swapped in?
One an application retrieves the password from the keychain, Apple cannot enforce that the key is used in a secure manner.
If these passwords are being swapped to disk by third party applications that are being granted the passwords, there's little Apple can do to prevent it.
Is KEYCHAIN swapping the passwords out, or programs getting the passwords through keychain?
FUSSY TIME FUSS
This bug better than 600 bugs in Oracle!root should not have it so easily!
the.security.cow
fixed in Tiger
Since no one else appears to have mentioned this yet: System Preferences -> Personal -> Security now has a checkbox for "Use secure virtual memory".
please help
i just got my computer and thought i would call myself the admin. the password i created was on a paper that my son threw away. i cant for the life of me remember what it was. is there anyone that can help me recover or change my password please?!?!?!?!?!?!?!?!?