Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > Finding admin password in the swapfile...

Finding admin password in the swapfile...
Thread Tools
VValdo
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 9, 2004, 01:13 AM
 
It has long been discussed that insecure stuff like passwords or encrypted files could be recovered from the swapfile (a kind of temporary virtual memory created on the hard drive when you go over your physical RAM)...

Today Macintouch reported now reporting that this line:

Code:
sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname
will show your password...

And indeed it does, at least for me.. making FileVault completely useless. FileVault is supposed to secure your HD even in cases where someone grabs your laptop. But a hacker with physical control of your computer only need mount the HD on another machine (via, say APPLE-T to start in firewire mode, or by booting off a CD) then run "strings" as above to discover your admin password, then reboot and log into your FileVault "protected" area.

Anyone have any thoughts about how this could be fixed or bypassed?

Ideas:

1. Apple could store the password in a binary/non-plaintext/encrypted format in memory (?)
2. Is there a way to keep it from being written into a swapfile?
3. Encrypt the swapfiles
4. Make sure the swapfiles is securely erased/rewritten on shutdown.

Your thoughts? This seems fairly serious to me...

W

PS-- looked for this topic on the board already, but didn't find it.
     
moki
Ambrosia - el Presidente
Join Date: Sep 2000
Location: Rochester, NY
Status: Offline
Reply With Quote
Jul 9, 2004, 01:31 AM
 
On the one machine I tried this on, it didn't work:

longname
Andrew Welch
password
/bin/tcsh
username
But anyway... if you have to have sudo access in order to do this... who cares? If you have sudo access, you can do just about anything you want to a machine.

..."If you know the admin password, you can find the admin password"...
Andrew Welch / el Presidente / Ambrosia Software, Inc.
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 9, 2004, 05:02 AM
 
Originally posted by moki:
But anyway... if you have to have sudo access in order to do this... who cares? If you have sudo access, you can do just about anything you want to a machine.

..."If you know the admin password, you can find the admin password"...
A couple points..

1. You don't need to have root password to run "strings" and then parse a file with grep. It's only required to access the /var/vm/swapfile0 file. But if you mount the system from a different machine, the sudo is not necessary.

2. The reason FileVault exists is so that if your computer gets physically stolen, there's no way a bad guy can get into the encrypted directory (usually the /User/Yourname folder). This is because they (1) don't have the admin password, therefore (2) they can't log in as admin to find your password, and (3) they can't decrypt the FileVaulted directory without your password. So being able to snag the admin password from the swapfile basically lets you get to a FileVaulted account, when you wouldn't otherwise be able to do so.

3. I'm wondering why your password didn't show and mine did. Theory #1-- it could be a random thing-- memory is swapped to disk when regular RAM fills up, so maybe you have more memory than me, or maybe some other stuff got swapped to disk instead. But Theory #2-- do you have FileVault turned on, and do you have your computer 'locked down' (ie-- don't automatically log in at startup, have sleep & screensaver set to prompt you for passwords, etc.)? If not, this may be why your password isn't stored in RAM and thus isn't swapped to disk.

4. Sometimes, you have so many applications open (or they're using so much RAM) that more than one swapfile becomes necessary. To check them all, try this.. (note the wildcard)

Code:
sudo strings -8 /var/vm/swapfile* |grep -A 4 -i longname
5. If you want to be sure it doesn't appear anywhere in the swapfiles, then just check for your password all by itself:

Code:
sudo strings -8 /var/vm/swapfile * | grep "YOURPASSWORD"
Be aware that the above involves typing your password directly in the terminal and it will be echoed, so anyone standing over your shoulder could see it, and anyone who has access to your .bash_history file will be able to see it as well (unless you delete this file)...


In any event, this still seems like a pretty big hole.

W
     
Ganesha
Senior User
Join Date: Jul 2002
Location: Arizona Wasteland
Status: Offline
Reply With Quote
Jul 9, 2004, 05:36 AM
 
My password didn't show up either with either string. But my systems have relatively large amount of real memory. Even when I loaded up my system to force swapping.

Are you running any application/haxies that require your admin password to run?
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 9, 2004, 06:05 AM
 
Wow, it showed up for me. That's a pretty ****ed up thing.. passwords should be shadowed throughout the system and now it's stored in plain-text somewhere in memory? Gross.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Jul 9, 2004, 06:54 AM
 
Turned up the passwords for both of my users. Wow. That's a little disturbing, but not very. If somebody is savvy and dedicated enough to sudo his way into my swapfile, I don't imagine he'd have a hard time getting into my account anyway.

Not to say it isn't a big security hole. It's just not a security hole that bothers me too much.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
philzilla
Occasionally Useful
Join Date: Jun 2001
Location: Liverpool, UK
Status: Offline
Reply With Quote
Jul 9, 2004, 07:12 AM
 
didn't show up for me
"Have sharp knives. Be creative. Cook to music" ~ maxelson
     
GENERAL_SMILEY
Mac Enthusiast
Join Date: May 2002
Status: Offline
Reply With Quote
Jul 9, 2004, 07:17 AM
 
This command works on mine, as I thought it would. Although in all honesty I would think it would work in all Unix variations, except those which encrypt their swap files - do any do this by default?

There are also differing levels of security / paranoia - do you want encryption / decryption of your swap on the fly so that nobody can just rip out your drive and grep your pass (or for that matter a trojan process running while you're Mac is on)? Or would you settle for a system whereby if the computer was shutdown correctly the swap would be inaccessible?

I have not seen anyway to encrypt the swap partition in OSX on the fly (I think Mandrake has this), but if you could settle for the second solution, you may achieve it by simply moving the Swap folder into the encrypted home directory, at least then when logged out of your Vault account, it's swap files would be inaccessible. I remember moving the swap folder in 10.1, presumably this can still be done? However I do not know at what stage the Swap folder is created in the boot process, is it all handled at startup, or on demand, or can it be changed without restarting(eg. after login)? God knows what would happen if it try to create the folder before the encrypted user is logged in.

Probably a simpler would be to simply secure wipe all your cache on logout - presumably some knowledgeable person could write a shell script for this?
I have Mac
     
Richard Edgar
Dedicated MacNNer
Join Date: Sep 2002
Status: Offline
Reply With Quote
Jul 9, 2004, 07:36 AM
 
This is a concern, because it reduces the effectiveness of the encryption (which is still an issue if the machine is stolen). And the plaintext password does have to be in the computer's memory at some point for some time. However, encrypting the swap files would be a particularly stupid way of solving the problem. All you need to do is ensure that the page holding the password is not eligible for swapping. I don't know about the details of OSX, but there must be some way of ensuring this - otherwise, the code for the swapper could get swapped out, with less than desirable consequences.
     
biscuit
Mac Enthusiast
Join Date: Jul 2002
Location: London, UK
Status: Offline
Reply With Quote
Jul 9, 2004, 07:39 AM
 
It shows up mine, which is a little disconcerting. But I'm not that concerned, if I've got anything really sensitive it goes in an encrypted disk image with a different password.

Shame that it sorta nukes FileVault though...

biscuit
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 9, 2004, 07:53 AM
 
Originally posted by Richard Edgar:
And the plaintext password does have to be in the computer's memory at some point for some time.
Why? If I type in a password, I expect it to be encrypted immediately and compared to the (also encrypted) password in the NI database somewhere. I understand that the input needs to be in a buffer for a short time, but the entry in the swap file doesn't look like one - it's more of a complete NI entry for a user with the password stored in plain-text. Why the hell is it stored that way? The encryption should be one-way only!
     
Richard Edgar
Dedicated MacNNer
Join Date: Sep 2002
Status: Offline
Reply With Quote
Jul 9, 2004, 07:56 AM
 
Why? If I type in a password, I expect it to be encrypted immediately and compared to the (also encrypted) password in the NI database somewhere. I understand that the input needs to be in a buffer for a short time
I think that you just answered your own question. Or is that buffer supposed to be in some magical 'not-memory' space?
     
VEGAN
Senior User
Join Date: Jun 2002
Location: UK
Status: Offline
Reply With Quote
Jul 9, 2004, 07:57 AM
 
Originally posted by entrox:
Why? If I type in a password, I expect it to be encrypted immediately and compared to the (also encrypted) password in the NI database somewhere. I understand that the input needs to be in a buffer for a short time, but the entry in the swap file doesn't look like one - it's more of a complete NI entry for a user with the password stored in plain-text. Why the hell is it stored that way? The encryption should be one-way only!
I don't know if it makes sense, but... you JUST typed your password to execute this command. So, doesn't it make sense that it's there at the time of the execution of this password? I can't confirm what happens to the password after that, but...
     
philzilla
Occasionally Useful
Join Date: Jun 2001
Location: Liverpool, UK
Status: Offline
Reply With Quote
Jul 9, 2004, 08:01 AM
 
Originally posted by VEGAN:
I don't know if it makes sense, but... you JUST typed your password to execute this command. So, doesn't it make sense that it's there at the time of the execution of this password? I can't confirm what happens to the password after that, but...
heh, exactly

so, why is it working on some Macs, and not others?
"Have sharp knives. Be creative. Cook to music" ~ maxelson
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 9, 2004, 08:20 AM
 
Originally posted by VEGAN:
I don't know if it makes sense, but... you JUST typed your password to execute this command. So, doesn't it make sense that it's there at the time of the execution of this password? I can't confirm what happens to the password after that, but...
Shadowed passwords don't work like that. You type in your password, it gets encrypted immediately and then compared to the database. There is no algorithm to determine the plain-text password from its encrypted form.

But that's beside the point: if you look closely at WHAT is stored, you'll notice it's not just some random buffer. It is actually an entry about your user: long user name, short user name, login shell etc.
Your password should never ever be stored in plain-text there.
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 9, 2004, 08:22 AM
 
Originally posted by Richard Edgar:
I think that you just answered your own question. Or is that buffer supposed to be in some magical 'not-memory' space?
Look exactly at the surrounding context. Does that look like a random input buffer to you?

Even then, such a buffer should be cleared immediately after use and marked to be non-swappable using mlock(). This is clearly a gaping security hole.
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 9, 2004, 08:29 AM
 
Originally posted by philzilla:
so, why is it working on some Macs, and not others?
Perhaps it's the automatic login functionality. My password is stored in the swap file and I have it enabled. What about others?
     
Richard Edgar
Dedicated MacNNer
Join Date: Sep 2002
Status: Offline
Reply With Quote
Jul 9, 2004, 08:33 AM
 
Look exactly at the surrounding context. Does that look like a random input buffer to you?
Not particularly, but that's not relevant - it just makes it easier to find. The bug is that the relevant memory page isn't locked into physical memory.
     
philzilla
Occasionally Useful
Join Date: Jun 2001
Location: Liverpool, UK
Status: Offline
Reply With Quote
Jul 9, 2004, 08:37 AM
 
Originally posted by entrox:
Perhaps it's the automatic login functionality. My password is stored in the swap file and I have it enabled. What about others?
just turned automatic login off on my iBook, rebooted it, tried the command again. still no password, but it did spit out some random/truncated lines from my .bash_profile, .bashrc, and .bash_history
"Have sharp knives. Be creative. Cook to music" ~ maxelson
     
hudson1
Dedicated MacNNer
Join Date: Aug 2002
Status: Offline
Reply With Quote
Jul 9, 2004, 08:54 AM
 
Question on the issue of a stolen computer....

If the computer was "off" when stolen, wouldn't that prevent a malicious retrieval of the password? It seems that simply turning the computer on would cause the re-creation of a new swapfile0 which, at that point, wouldn't have the admin password. Or, I could be entirely wrong if the system loads the password into memory before it's entered by the user.
     
moki
Ambrosia - el Presidente
Join Date: Sep 2000
Location: Rochester, NY
Status: Offline
Reply With Quote
Jul 9, 2004, 09:04 AM
 
Well, assuming it is a stolen PowerBook, a savvy thief could theoretically boot it into firewire mode, attach it to another computer, and munge through the swapfiles hoping to get lucky (it doesn't seem to work consistently), then use the password (if they find it) to log in and decrypt your home directory.

Certainly possible, and a hole that should be plugged.

I think most thieves could care less about the data on your hard drive, though, and likely just want the computer... but people having access to your private data is never a good thing.
Andrew Welch / el Presidente / Ambrosia Software, Inc.
     
VEGAN
Senior User
Join Date: Jun 2002
Location: UK
Status: Offline
Reply With Quote
Jul 9, 2004, 09:35 AM
 
Originally posted by moki:
Well, assuming it is a stolen PowerBook, a savvy thief could theoretically boot it into firewire mode, attach it to another computer, and munge through the swapfiles hoping to get lucky (it doesn't seem to work consistently), then use the password (if they find it) to log in and decrypt your home directory.

Certainly possible, and a hole that should be plugged.

I think most thieves could care less about the data on your hard drive, though, and likely just want the computer... but people having access to your private data is never a good thing.
I'm not sure one would have to go through even that much of trouble. Just use the Mac OS X install CD to reset the password and you are in.
If you have physical access to the computer, you are `root'. Everyone knows that [who deal with computer security].
     
Richard Edgar
Dedicated MacNNer
Join Date: Sep 2002
Status: Offline
Reply With Quote
Jul 9, 2004, 09:59 AM
 
I think most thieves could care less about the data on your hard drive
If they could care less, then they're rather likely to be prepared to jump through the odd hoop to get the data, aren't they?
     
diskgolfking
Junior Member
Join Date: Mar 2004
Status: Offline
Reply With Quote
Jul 9, 2004, 10:04 AM
 
For the people whose passwords showed up:

Has anyone tried logging in with a *different* user and doing this test?

The reason I ask is that it's possible that the password will show up in the swapfile for a while when you are logged in but that logging off will remove it (because might that not change or remove the swap file?). If that's the case then someone who steals your computer will not be able to get it.
     
diskgolfking
Junior Member
Join Date: Mar 2004
Status: Offline
Reply With Quote
Jul 9, 2004, 10:05 AM
 
Originally posted by VEGAN:
I'm not sure one would have to go through even that much of trouble. Just use the Mac OS X install CD to reset the password and you are in.
If you have physical access to the computer, you are `root'. Everyone knows that [who deal with computer security].
We're talking about FileVault. What you described would give you access to normal data but not FileVault protected data.
     
JKT
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status: Offline
Reply With Quote
Jul 9, 2004, 10:18 AM
 
Password shows in my swapfile, of which I currently have 5 (totalling 1GB). I think this was first reported at MacFixIt last week some time. There were suggestions there that it might be due to exposure of the password by some piece(s) of software rather than the OS itself, which could be why only some of us are seeing it when searched for and others aren't.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Jul 9, 2004, 06:05 PM
 
Originally posted by VEGAN:
you JUST typed your password to execute this command. So, doesn't it make sense that it's there at the time of the execution of this password? I can't confirm what happens to the password after that, but...
If string buffers are being paged out as soon as you create them, you really need more memory.

Besides which, as I said, it turns up full user records complete with my long and short name (which I did not type) and information on my other user whose password I did not just type.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
chabig
Addicted to MacNN
Join Date: Jun 1999
Location: Las Vegas, NV, USA
Status: Offline
Reply With Quote
Jul 9, 2004, 07:44 PM
 
Originally posted by moki:
Well, assuming it is a stolen PowerBook, a savvy thief could theoretically boot it into firewire mode, attach it to another computer, and munge through the swapfiles hoping to get lucky (it doesn't seem to work consistently), then use the password (if they find it) to log in and decrypt your home directory.
This is not possible. The swapfiles don't exist when the machine is shut down.

Chris
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Jul 9, 2004, 09:06 PM
 
Originally posted by chabig:
This is not possible. The swapfiles don't exist when the machine is shut down.
Take out the battery, and the machine won't have time to clear out the swapfiles. Then remove the hard drive and put it into the machine (don't use TDM, just in case Apple had the foresight to scan for swapfiles on boot into TDM) and scan away. It's harder, but if you've stolen the machine already then you have all the time in the world.

Alas, this is a case where once again, You Are Hosed if someone can get physical access to your machine. If they're on a network then this trick is useless; you need sudo access to do it, and if you have that then you are already hosed; the only reason to grab the passwords from the swapfile is to try them elsewhere (though this is not by any means a negligible thing).

Let's look over those four suggestions:
1. Apple could store the password in a binary/non-plaintext/encrypted format in memory (?)
No good. Wherever else it stores the password, it has to store what the user typed in, even if only long enough to encrypt it.
2. Is there a way to keep it from being written into a swapfile?
It's possible to keep certain areas of memory from being written into a swapfile. In fact, all virtual memory systems must have such a system, because you have to keep the VM system itself from being written out to a swapfile (otherwise, how would you get it back into memory?)

This said, I don't know how fine-grained the control over this is. At least in theory, it should be possible to force password buffers into this "wired zone", such that it never got swapped out. Next question, though: how feasible is it?
3. Encrypt the swapfiles
Not practical. Aside from the performance issues, keep in mind that the encryption/decryption routines would have to be wired. For that matter, where do you store the key to decrypt?
4. Make sure the swapfiles is securely erased/rewritten on shutdown.
As I mentioned before, this can easily be circumvented by cutting power to the device.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 9, 2004, 10:06 PM
 
Hmmm.. Well this just sucks.

I think this was said already, but why not store the password in memory as a one-way hash so that a comparison of user input could be made-- assuming that this is sitting in memory for auto-confirmation upon wake from sleep and the screensaver?

If that's not why its in memory.. then why else would it be needed? I can see it being there for a few seconds (to remember the user's input, etc.) but it seems to be hanging around for a lot of people, including me. Which sucks. And why is it so close in memory to other identifiable data, making it so easy to find..

Hmm. As far as encrypting the entire swapfile, might as well encrypt it in memory than do the entire file, right?

W
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 10, 2004, 06:17 AM
 
Originally posted by Millennium:
No good. Wherever else it stores the password, it has to store what the user typed in, even if only long enough to encrypt it.
Allocate a buffer, mark it non-swappable, get input from user, encrypt it, clear buffer, unlock and free it. This shouldn't be too hard for an Apple engineer, should it?

This said, I don't know how fine-grained the control over this is. At least in theory, it should be possible to force password buffers into this "wired zone", such that it never got swapped out. Next question, though: how feasible is it?
man 2 mlock

The only gotcha is that you need to have administrative privileges to lock random memory buffers, but everything that asks for your admin password should be in this group anyway.
( Last edited by entrox; Jul 10, 2004 at 06:27 AM. )
     
Thinine
Mac Elite
Join Date: Jul 2002
Status: Offline
Reply With Quote
Jul 10, 2004, 03:30 PM
 
This is stupid. If a thief can boot your machine into target mode, they can boot off a system disk and change your password, so I don't see the problem. This 'hack' only works if they steal your machine while it's on and then don't shut it down properly. And has anyone tested it like this? To see if the password is visible when scanning from another computer? For all you know, it doesn't work then.
     
chabig
Addicted to MacNN
Join Date: Jun 1999
Location: Las Vegas, NV, USA
Status: Offline
Reply With Quote
Jul 10, 2004, 07:28 PM
 
I agree. I don't see this a big security problem.

Chris
     
wadesworld
Grizzled Veteran
Join Date: Apr 2001
Status: Offline
Reply With Quote
Jul 10, 2004, 08:58 PM
 
I don't think it's a huge issue. I'm sure that Apple will probably do more to reduce or eliminate the chances of it happening in the future, but it is not a big deal for most users.

Wade
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 10, 2004, 09:23 PM
 
Whoa, whoa.

Hang on a second, everyone. Those of you who don't use FileVault may not see it is a big deal, but for those who trust FV to keep financial information, passwords, medical data, business info, national security secrets, etc. private, it's important.

Originally posted by Thinine:
This is stupid. If a thief can boot your machine into target mode, they can boot off a system disk and change your password, so I don't see the problem.
They can change your accounts password, but they can't get into your encrypted directory with your newly changed password. They'd need your old one. So your data should still be safe. I haven't tried this, but I would presume that after logging in, the system would ask for the OLD password (or your system's Master Password) as it booted, because otherwise it would never be able to unencrypt and mount your home directory.

This 'hack' only works if they steal your machine while it's on and then don't shut it down properly. And has anyone tested it like this? To see if the password is visible when scanning from another computer? For all you know, it doesn't work then.
This isn't true. #1. The swap is not deleted if the computer is put to sleep rather than shutdown/restarted. So anyone stealing a sleeping computer who pops the battery would be able to use this hack. #2. According to this discussion, the swapfile is deleted on STARTUP not SHUTDOWN. I havent' confirmed this, but if its' true, it means that ANY computer-- whether on, sleeping, or shut down, has a significant probability of a cleartext password in the swapfile!

So, to rephrase what you said, "this hack only works if they pop the battery out while it's on OR asleep OR (apparently) shut down properly."

And the password WOULD be visible when scanning from another computer because the swapfile is totally unencrypted.

For those who depend on FileVault for security, this seems to be a big, big hole.

W
     
Thinine
Mac Elite
Join Date: Jul 2002
Status: Offline
Reply With Quote
Jul 10, 2004, 09:33 PM
 
Someone test this and see if it actually works remotely.
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 10, 2004, 09:44 PM
 
One last argument to hopefully make my point that you should care re this...

What applies to FileVault applies equally to the Keychain. Now ordinarily, let's say you don't use FileVault, so if someone steals your computer, they can get into your files. Maybe you don't care. But what about all the info stored in the keychain?

This includes:

Airport Network Passwords
application passwords
disk image passwords
Internet passwords
iTools passwords
Secure Notes (stuff you added manually)
etc.

Right now that stuff is locked and not visible by default. Certain applications may have been authorized to have ACCESS to information in the keychain, but if you run "Keychain Access" and try to see the passwords themselves, you can't. You need the user's main account password.

Well, if our bad guy thief has snatched this password from the swapfile, they now have access to seeing all the stuff in the keychain as well.

Sure, they can run your applications and be able to USE the password (unless you have it set to ask every time you run it-- and because of this hole, maybe you should), but at least they can't see the passwords themselves.

Worst of all- for those of you trusting the "Secure Note" feature of Keychain Access to keep notes secure, this would be the ONLY way they'd get access, I think, even in a non filevaulted machine.

Anyway, I haven't fully thought out all the ramifications, but I just wanted to point out that this hole could be of interest to non-FileVault users as well.

W
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 10, 2004, 11:15 PM
 
Originally posted by VValdo:
Sure, they can run your applications and be able to USE the password (unless you have it set to ask every time you run it-- and because of this hole, maybe you should)....
1. I'm stupid. Obviously if they have the password they can type it in if prompted. So forget that as "added security". And setting up a second password just for the keychain probably won't do much either, since it might end up in the swapfile too. So unless I'm mistaken, this hole completely exposes the keychain's contents.

2. One difference between being able to USE your passwords and SEE your password is that many systems require a current password be typed in to change it to something else. So a bad guy could use this hole to lock you out of your own accounts.

W
     
ginoledesma
Mac Elite
Join Date: Apr 2000
Location: Los Angeles, CA
Status: Offline
Reply With Quote
Jul 11, 2004, 12:48 AM
 
I've 3 accounts on my Mac and none of them turned up their passwords. My primary account is automatically logged-in, a second guest account with an empty password, and a third account I setup to try this out with a test password.

It is disconcerting to know that your password is stored in the swap file, and in plaintext no less. I thought Apple already learned this bit when they moved from the relatively-weak encryption used in the early versions of Mac OS X to the current ones (they moved to Md% already, right?).

Thank goodness my password isn't easily recognizable, as its mostly "garbage" to begin with.
     
Rainy Day
Grizzled Veteran
Join Date: Nov 2001
Location: Oregon
Status: Offline
Reply With Quote
Jul 11, 2004, 03:05 PM
 
Originally posted by VValdo:
the swapfile is deleted on STARTUP not SHUTDOWN. I havent' confirmed this, but if its' true, it means that ANY computer-- whether on, sleeping, or shut down, has a significant probability of a cleartext password in the swapfile!
I can confirm that the startup code does look for and delete swapfiles. Whether or not the same thing happens on shutdown as well, i don't know. But the comments in the startup code lead me to believe that something may also be in the shutdown code too.

So, to rephrase what you said, "this hack only works if they pop the battery out while it's on OR asleep OR (apparently) shut down properly."
Well, even if the swapfiles are deleted, they aren't wiped from the disk, so the data is still on the disk! This might change in a future version of MacOS X.
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 11, 2004, 04:40 PM
 
OK I have tested this on various Mac OS X systems...

Sometimes I get nothing.
Sometimes I get a password or two or more.
Sometimes I get the admin password and it may be padded with a few extra characters.
Sometimes I get stuff that is not password related at all.

I have gotten the above results from many different Mac OS X systems including Mac OS X server v10.3.x, Mac OS X server v10.2.x, Mac OS X v10.2.x and Mac OS X v10.3.x. On all of these versions I was able to get at least one admin password at least once. I tested about 20 different Macs. In most cases once I got the admin password on one machine I had it on all of them within that subnet or lab. I even found one machine which for some inexplicable reason the /var/vm/swapfile* s were world readable!

In general this is not a remotely exploitable problem. Even if the attacker has an account on the system and can log in via ssh they can't read /var/vm/swapfile* s.

In general it is not a locally exploitable problem if the OF password is set AND the machine is physically locked(case lock). As are all our lab machines.

In general it IS a problem if the attacker can make the machine boot from a USB or firewire drive or can remove the drive and mount it on a different machine. Just because some people have not been able to extract a password at some given instant it does not mean that this will always be the case.

VVAldo is correct in that mlock() and munlock() are the system calls for preventing memory areas from being swapped to disk. There may be other methods but I don't know enough about it.

My guess is that the reason for inconsistent results is that some programs/apps/utils/whatever may do the mlock() thing correctly and some do not. But which ones?? Is there a command to figure out what calls a program makes without running the program? I was looking at gprof. Any such program that makes mlock() system calls would have to be setgid root in order to work. Which should not be too much of a problem since most all programs that mess around with passwords are setgid or setuid root anyhow.

There is also the problem of core dumps. Which should be turned off by default. Does anyone know how to confirm that core dumps are turned off?
-DU-...etc...
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 11, 2004, 11:26 PM
 
Originally posted by utidjian:
My guess is that the reason for inconsistent results is that some programs/apps/utils/whatever may do the mlock() thing correctly and some do not. But which ones?? Is there a command to figure out what calls a program makes without running the program? I was looking at gprof. Any such program that makes mlock() system calls would have to be setgid root in order to work. Which should not be too much of a problem since most all programs that mess around with passwords are setgid or setuid root anyhow.
As I understand it, and I'm certainly no expert, and with unix apps notwithstanding, only Apple-provided code should be directly asking the user for their password and/or holding it in memory. Third-party user-level apps should be going through Apple's security APIs such as Apple's Authorization Services and Keychain Services, etc. (Once a 3rd party app gets private data out of the keychain that's a seperate matter)

Originally posted by utidjian:

There is also the problem of core dumps. Which should be turned off by default. Does anyone know how to confirm that core dumps are turned off?
I think it's off by default in OS X. in 10.3.x it goes in

/cores

To see if it's on for you, type
Code:
ulimit -a
if "core file size" is set to zero, you're cool. To turn core dumps on for whatever reason, place this line in /etc/hostconfig:

Code:
COREDUMPS=-YES-
W
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Jul 11, 2004, 11:35 PM
 
I wonder what happens if this command is issued on other *nixes. Is this an OS X only issue?

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Jul 12, 2004, 12:36 AM
 
Originally posted by entrox:
Allocate a buffer, mark it non-swappable, get input from user, encrypt it, clear buffer, unlock and free it. This shouldn't be too hard for an Apple engineer, should it?
Yes, Apple should be able to fix this for the OS, and even for Apple bundled applications.

The problem really is: WHICH applications/processes are actually leaving those passwords in your swap files? The real fix for this problem is to have every application that ever uses your password do the right thing as well.

Thankfully, Apple provide a nice API for developers to use for authentication, so that if Apple fix it in their own software, it should automatically fix it for most compliant applications out there. But who knows how many applications out there do their own thing.

In think that before we take it too far, we need to determine which processes/applications/services are responsible for the problem.
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Jul 12, 2004, 12:40 AM
 
This is a GENERAL UNIX problem. Not just Mac OS X.

I've just searched for my password in the swap files on my Solaris workstation here. It is still running, but has found it 7 times so far.

So it certainly affects Solaris as well (one of the most respected Unix OS's out there).
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Jul 12, 2004, 12:45 AM
 
I've always maintained that a real vault is much safer than FileVault. For critically important data, the machine should be kept in a physically secure environment (when possible).

That way you eliminate the many many security problems with direct physical access to a machine.
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 12, 2004, 01:03 AM
 
Many thanks for the answers VValdo.

I suppose it could just be the Apple APIs that are the root of the problem and the reason for inconsistent results is that not all systems are under the same load and/or been up the same time. I don't think there is any real way to predict when any particular piece of memory will be swapped to disk. There are probably ways to force it, such as start some really memory intensive processes (PS, a game, write a prog that writes to blocks of RAM).

There was problem before with the screen lock. IIRC it was back in 10.1.5 days when one could force a locked screen login window to die and get the user who locked the screen desktop. This was fixed a while ago.
-DU-...etc...
     
Sarc
Mac Elite
Join Date: Sep 2001
Location: Chile
Status: Offline
Reply With Quote
Jul 12, 2004, 02:56 AM
 
about the string's random behavior, can't it be related to uptime (in terms of use)?
for example, could it be that the password you get from the swapfile is the one you use to login and it won't show up on the swapfile until you have used your computer long enough to fill the memory ?

btw. my uptime is 42 days and I have used a bunch off apps. that required my admin pass since then, right now I can think of Toast and Screen Saver (Lock Screen).
:: frankenstein / lcd-less TiBook / 1GHz / radeon 9000 64MB / 1GB RAM / w/ext. 250GB fw drive / noname usb bluetooth dongle / d-link usb 2.0 pcmcia card / X.5.8
:: unibody macbook pro / 2.4 Ghz C2D / 6GB RAM / dell 2407wfp - X.6.3
     
Thinine
Mac Elite
Join Date: Jul 2002
Status: Offline
Reply With Quote
Jul 12, 2004, 04:00 AM
 
Has anyone tested this remotely? I mean, improperly shutdown a machine and then connect it to another and scan the swap file? And still find passwords? Until the password is recovered in that way, this is a total nonissue.
     
WJMoore
Grizzled Veteran
Join Date: Jan 2002
Location: Melbourne, Australia
Status: Offline
Reply With Quote
Jul 12, 2004, 05:07 AM
 
This is the original post to security focus. The issue was reported to Apple on Jun 21. The post also suggests the use of mlock as a solution (as already mentioned in this thread). Also this is Apple code at fault. Primarily the loginwindow process that presents the login window that you login into. Hopefully this will clear up some of the speculation and rumours going on.

From: Matt Johnston <matt@***.asn.au>
Date: Fri, 25 Jun 2004 17:48:21 +0800
Subject: Mac OS X stores login/Keychain/FileVault passwords on disk
To: [email protected]

It seems that Mac OS X (10.3.4 tested) doesn't bother clearing memory
containing sensitive data, or using mlock() to avoid swapping.

A quick grep of the swapfiles will show up various morsels:

rez:~> sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname
longname
password
<user's password here>
/bin/zsh
username
---
... various other occurrences follow

Grepping for context around "password" also shows up results, and grepping
for portions of a Keychain password (differing from the login password)
will also get results. It appears that loginwindow is one of the apps involved,
I haven't investigated what else is involved. The amount of memory and usage
patterns of the machine will affect what gets swapped, though loginwindow seems
likely to get swapped early since it is seldom used after login.

Obviously this is only of interest if an attacker has root (or physical)
access to a machine, however it does make FileVault or Keychain encryption
fairly useless. It appears that the swapfiles are removed on shutdown or
startup, though not wiped - pulling the power from a sleeping machine, and/or
booting from CD, would quite easily retrieve the password(s).

Reported to Apple on 21 June, I haven't had any response. It'd be nice if
they at least said "we're taking a look if it's an issue".

Matt
     
 
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 04:31 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,