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... (Page 2)
Thread Tools
jaiqua
Junior Member
Join Date: Jan 2004
Location: Call off the search.
Status: Offline
Reply With Quote
Jul 12, 2004, 05:47 AM
 
There was a series of articles on passwords lying dormant on computers for years.

http://www.newscientist.com/news/news.jsp?id=ns99995064

http://slashdot.org/article.pl?sid=0...id=126&tid=172
the navajo know
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 12, 2004, 05:58 AM
 
It appears that loginwindow is one of the apps involved
I have a guess at why. When your computer wakes from sleep or comes back from the screensaver, it hits you with the "ENTER YOUR PASSWORD" prompt almost instantly (if you have this feature turned on). While it could read the pw from the hard drive, maybe they just decided to keep it in memory so it wouldn't have to wait for the HD to spin up or if the user's info were on a remote HD that might not be connected...?

I thought that maybe it stores the cleartext password rather than an MD5 hash or whatever because if it were case-insensitive, a comparison with the user's guess wouldn't work. But it's case sensitive. So... is there any other reason people can think of why (1) hashes aren't stored in memory instead or (2) the memory couldn't be locked so that it isn't swapped?

I do hope this is addressed soon.

W

PS-- this may be a problem in other Unixes (Unices? Unixen?), but it's still a serious problem, especially since FileVault has been touted as so secure. Apple can't be responsible for third-party apps being cavalier, but at least they should address this if it's addressable. And I think it is. Check out this info posted by a PGPdisk user on Macintouch:

PGPdisk takes special care to avoid security problems that other programs may not. These include the following:
_ Passphrase erasure - When you enter a passphrase, PGPdisk uses it only for a brief time, then erases it from memory. PGPdisk also avoids making copies of the passphrase. The result is that your passphrase typically remains in memory for only a fraction of a second. This feature is crucially important -- if the passphrase remained in memory, someone could search for it in your computer memory while you were away from the machine. You would not know it, but they would then have full access to any PGPdisk volumes protected by this passphrase.
_ Virtual memory protection - Your passphrase or other keys could be written to disk as part of the virtual memory system swapping memory to disk. PGPdisk takes care that the passphrases and keys are never written to disk. This feature is important because someone could scan the virtual memory file looking for passphrases.
     
JKT
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status: Offline
Reply With Quote
Jul 12, 2004, 06:46 AM
 
Originally posted by VValdo:
I have a guess at why. When your computer wakes from sleep or comes back from the screensaver, it hits you with the "ENTER YOUR PASSWORD" prompt almost instantly (if you have this feature turned on). While it could read the pw from the hard drive, maybe they just decided to keep it in memory so it wouldn't have to wait for the HD to spin up or if the user's info were on a remote HD that might not be connected...?

I thought that maybe it stores the cleartext password rather than an MD5 hash or whatever because if it were case-insensitive, a comparison with the user's guess wouldn't work. But it's case sensitive. So... is there any other reason people can think of why (1) hashes aren't stored in memory instead or (2) the memory couldn't be locked so that it isn't swapped?

I do hope this is addressed soon.

W

PS-- this may be a problem in other Unixes (Unices? Unixen?), but it's still a serious problem, especially since FileVault has been touted as so secure. Apple can't be responsible for third-party apps being cavalier, but at least they should address this if it's addressable. And I think it is. Check out this info posted by a PGPdisk user on Macintouch:
OK, can we get a show of hands as to who is and who isn't able to find their password in the swapfile(s) and who is using the password protected screensaver, to see if there is indeed a pattern to this?

I'll start -

Password found in swapfile - yes
Use the Password protected screensaver - yes
     
VEGAN
Senior User
Join Date: Jun 2002
Location: UK
Status: Offline
Reply With Quote
Jul 12, 2004, 07:12 AM
 
Originally posted by JKT:
OK, can we get a show of hands as to who is and who isn't able to find their password in the swapfile(s) and who is using the password protected screensaver, to see if there is indeed a pattern to this?

I'll start -

Password found in swapfile - yes
Use the Password protected screensaver - yes
yes
yes
     
qnxde
Grizzled Veteran
Join Date: Jul 2001
Location: Sydney, Australia
Status: Offline
Reply With Quote
Jul 12, 2004, 07:35 AM
 
10.4, no password protection on bootup or screensaver, no output from that command.

You can't eat all those hamburgers, you hear me you ridiculous man?
     
JLL
Professional Poster
Join Date: Apr 1999
Location: Copenhagen, Denmark
Status: Offline
Reply With Quote
Jul 12, 2004, 07:56 AM
 
Password found in swapfile - no output at all (10.3.4)
Use the Password protected screensaver - yes
JLL

- My opinions may have changed, but not the fact that I am right.
     
chris v
Addicted to MacNN
Join Date: Jan 2001
Location: The Sar Chasm
Status: Offline
Reply With Quote
Jul 12, 2004, 08:38 AM
 
Originally posted by JKT:
O
Password found in swapfile - yes
Use the Password protected screensaver - yes
No, and no. Hmmm...

CV

When a true genius appears in the world you may know him by this sign, that the dunces are all in confederacy against him. -- Jonathan Swift.
     
jasong
Mac Elite
Join Date: Mar 2000
Location: Allston, MA, USA
Status: Offline
Reply With Quote
Jul 12, 2004, 08:57 AM
 
Yes
No
     
biscuit
Mac Enthusiast
Join Date: Jul 2002
Location: London, UK
Status: Offline
Reply With Quote
Jul 12, 2004, 09:23 AM
 
Password found in swapfile - yes
Use the Password protected screensaver - yes
     
sjampoo
Fresh-Faced Recruit
Join Date: Nov 2003
Location: Amsterdam
Status: Offline
Reply With Quote
Jul 12, 2004, 10:19 AM
 
Originally posted by Big Mac:
I wonder what happens if this command is issued on other *nixes. Is this an OS X only issue?
Yes, as long as swap space is being used "secret" stuff could pop up overthere. Maybe it's time to encrypt the swap partition. It comes as an easy-to-enable option on OpenBSD and with a few adjustments to the freeBSD kernel it could be made possible over there. I smell a nice project for darwin developers here.

However a filevault password should *NEVER* pop up in a swapfile.
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 12, 2004, 10:57 AM
 
Originally posted by JKT:
OK, can we get a show of hands as to who is and who isn't able to find their password in the swapfile(s) and who is using the password protected screensaver, to see if there is indeed a pattern to this?

I'll start -

Password found in swapfile - yes
Use the Password protected screensaver - yes
There is really no point in doing this. The data you get from this will not tell you anything that we don't already know.

The problem is definitely with the Apple authentication app(s). The main authentication app is loginwindow.app. It seems to handle all the FileVault and other authentication stuff.

I don't know about keychain. I do know that keychain, when unlocked, will restore passwords to their plaintext form. If the keychain interface is left open long enough it could possibly be swapped to disk. But I don't know whether keychain keeps the authentication strings in RAM that can be swapped to disk.

From what I can tell it is obvious that loginwindow does keep the plaintext string in RAM for a long time. Sometimes long enough to be swapped to disk.

Since one of the first things people do after they turn on their system is log in... their password is loaded into RAM early on. After that, depending on how much RAM they have and how memory intensive in total their apps are... the region of memory holding their password is going to get swapped out. It could be that when anything gets swapped the decision of what to swap is based on FIFO (first in, first out). Since loginwindow was certainly one of the earliest apps to use since bootup it is likely that chunk of memory that contains loginwindow info will be one of the earliest that are swapped to disk.

There is also the problem other apps that require authentication. Most use the Keychain. It may be that some apps require the keychain to cough up the password in plain text. iChat, .Mac, iTunes-Store, Mail.app, Safari, iCal are some of the Apple supplied apps that may ask for a password from the Keychain or directly from the user.

Then there are all the third party apps that may ask for passwords for various things... gaim, AIM, Mozilla, Firefox, Eudora, IE, Office-X, and so on. Any of those apps may have a different policy on how it handles password strings. It may even be better than Apples current scheme for loginwindow.app. If for no other reason, that is why one should never use the same password for the admin user as one does for any other application or user.

So... with all the variables that can affect this problem I don't think you are going to get anything meaningful from a show-of-hands-two-variable type poll.
-DU-...etc...
     
moki
Ambrosia - el Presidente
Join Date: Sep 2000
Location: Rochester, NY
Status: Offline
Reply With Quote
Jul 12, 2004, 12:37 PM
 
Originally posted by JKT:
Password found in swapfile - yes
Use the Password protected screensaver - yes
No
Yes
Andrew Welch / el Presidente / Ambrosia Software, Inc.
     
JKT
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status: Offline
Reply With Quote
Jul 12, 2004, 01:00 PM
 
Well, it might be useless for determining why it is happening, but I think we can safely say that it isn't solely due to the screensaver password protection on the basis of the results so far... put your hands down everyone
     
madmacgames
Grizzled Veteran
Join Date: Oct 2003
Status: Offline
Reply With Quote
Jul 12, 2004, 01:04 PM
 
I have 5 swap files on my drive and scanned all 5 of them, and it is not found anywhere in the swap on my machine.
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 12, 2004, 02:22 PM
 
Originally posted by JKT:
Well, it might be useless for determining why it is happening, but I think we can safely say that it isn't solely due to the screensaver password protection on the basis of the results so far... put your hands down everyone
Well we already knew that... or some of us did. On some of the systems I tested already they did not have screensaver password protection turned on.

On one system that I am currently testing it would return nothing for the query. It is a 17" FP iMac with 1G RAM and Mac OS X 10.3.4 and all current updates. It has been up 6 days and 5 hours. It had 500M or so of "free" memory accoring to top and only listed 2 pageouts. So I loaded it up until it started swapping. Logged in two more users, opened just about every app on the system (all Apple supplied apps, no IE). Finally got it to swap... and finally got something for the query... but no passwords.
Next I started fink selfupdate then fink update-all. It has been a while so those commands are giving the system a real workout. Fink does not require the admin password to run. I am running it mainly to load up the resources and force some swapping. Now I am getting some user passwords from the query. Though not an admin password yet. I now have about 150K pageouts.

I will try something similar on different machines. Like only the admin user logged in via ssh which may bypass the loginwindow altogether. More on that later...
-DU-...etc...
     
K++
Senior User
Join Date: Jan 2002
Location: NYC
Status: Offline
Reply With Quote
Jul 12, 2004, 04:14 PM
 
Originally posted by VValdo:
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.



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 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
ugh, shut up.
The FileVault password IS NOT YOUR USER PASSWORD. If you were foolish enough to make them the same, the is your fault, again, your fault. The filevault password is stored on your keychain, and it is accessed to automatically unlock your filevault for you. When I did use FV, these were different passwords, if your so concerned they should have been different passwords in the first place and you should have opted not to add it to your keychain then you wouldn't be moaning about this.

I'm not saying this isn't a security hole, just not the one you keep crying about. Shut up about FileVault, this in no way makes it less secure. As for the suggestions for fixing this, what everyone needs to do is wait for Apple to fix it, because though I have no idea what could possibly be causing it to ever be written to memory in such a way, I would trust that the people who actually wrote it and more importantly, have access to its source CAN. So tell Appl to fix it, crying about it doesn't get it done.

Lastly, if your FileVault is so precious why are the passwords to your user and your filevault one and the same? Guess your no Frodo.
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Jul 12, 2004, 07:13 PM
 
Originally posted by K++:
ugh, shut up.
The FileVault password IS NOT YOUR USER PASSWORD. If you were foolish enough to make them the same, the is your fault, again, your fault. The filevault password is stored on your keychain, and it is accessed to automatically unlock your filevault for you. When I did use FV, these were different passwords, if your so concerned they should have been different passwords in the first place and you should have opted not to add it to your keychain then you wouldn't be moaning about this.

I'm not saying this isn't a security hole, just not the one you keep crying about. Shut up about FileVault, this in no way makes it less secure. As for the suggestions for fixing this, what everyone needs to do is wait for Apple to fix it, because though I have no idea what could possibly be causing it to ever be written to memory in such a way, I would trust that the people who actually wrote it and more importantly, have access to its source CAN. So tell Appl to fix it, crying about it doesn't get it done.

Lastly, if your FileVault is so precious why are the passwords to your user and your filevault one and the same? Guess your no Frodo.
I don't use file vault so this is not to stir the pot, but is a genuine question...

If you login password can be used to automatically unlock the KeyChain and hence access FileVault encrypted data, what difference does it make is your login password and FileVault password are the same or not?

I guess what you're saying is that you should not store your FileVault password in the KeyChain?

I certainly agree with that... I don't store anything in the KeyChain, except for the most trivial passwords (eg, iChat). Not email, not anything of any importance.
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 12, 2004, 07:44 PM
 
Originally posted by K++:
ugh, shut up.
The FileVault password IS NOT YOUR USER PASSWORD. If you were foolish enough to make them the same, the is your fault, again, your fault. The filevault password is stored on your keychain, and it is accessed to automatically unlock your filevault for you. When I did use FV, these were different passwords, if your so concerned they should have been different passwords in the first place and you should have opted not to add it to your keychain then you wouldn't be moaning about this.

I'm not saying this isn't a security hole, just not the one you keep crying about. Shut up about FileVault, this in no way makes it less secure.

[snip]

Lastly, if your FileVault is so precious why are the passwords to your user and your filevault one and the same? Guess your no Frodo.
Sigh.

1. According to the FileVault System Preferences panel, "Your files will be encrypted using your login password."


See?

2. According to Apple, FileVault encrypts your home directory so that it is recoverable using either (1) your login password or (2) a master password, otherwise known as a "safety net" password, for the entire computer. When you create your FV, you or your admin should have already set up the system's master password, but it isn't required.

3. Since you insist you used different passwords for your FV and login, I'm bettin' you (A) are using some futuristic OS X that the rest of us haven't gotten yet or (B) didn't read the System Preference panel carefully enough to realize what you entered was actually a master system-wide password. And of course, since you were never prompted for your "FileVault Password" at login, you assumed it was coming from the Keychain somehow. But gee, if you thought for one second before typing, maybe you would have wondered how the system could have gotten to your FileVault-encrypted Keychain file in ~/Library/Keychains w/o already having the password it needed to unencrypt itself?

4. If you had thought for two seconds, you might have actually checked your keychain to see if the FileVault password is there, which it isn't.

5. And yes, there is a System keychain. And no, your FileVault password isn't there either. (the master FileVault password is in /Library/Keychains/FileVaultMaster.keychain, jest so ya know).

Thanks for writin', Sam. Luv ya.

W
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 12, 2004, 07:54 PM
 
Originally posted by utidjian:
... only the admin user logged in via ssh which may bypass the loginwindow altogether. More on that later...
Ok tried it. Logged in via ssh, rebooted, logged back in via ssh as admin, ran 'fink selfupdate' then 'fink update-all'. I got about 54K pageouts. At no time could I get any result to the query using 'longname' as the string. I tried other strings but never got a plaintext password.

This means that ssh and sudo most likely do not store the the password string in RAM that is allowed to swap. In fact ssh can't do that because it never "sees" the plaintext password on the receiving end.

This means (to me at least) that loginwindow.app is one of the culprits. Though it may not be the only one.
-DU-...etc...
     
unregistered
Forum Regular
Join Date: Mar 2001
Status: Offline
Reply With Quote
Jul 12, 2004, 10:19 PM
 
What I am interested in is how many many people on this thread have been grepping around for their password and now have multiple copies of it in their .bash_history file? Now all we need is for some trojan to come along to pickup everyone's history file and pass it back to some sinister individual.
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 12, 2004, 10:46 PM
 
Originally posted by unregistered:
What I am interested in is how many many people on this thread have been grepping around for their password and now have multiple copies of it in their .bash_history file? Now all we need is for some trojan to come along to pickup everyone's history file and pass it back to some sinister individual.
I know you're probably joking, but post #3 in this thread does mention deleting the .bash_history file for that exact reason. If you're using an earlier version of OS X, which used tcsh by default, I think the previous commands are stored in ~/.history.

W
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 12, 2004, 10:50 PM
 
Originally posted by unregistered:
What I am interested in is how many many people on this thread have been grepping around for their password and now have multiple copies of it in their .bash_history file? Now all we need is for some trojan to come along to pickup everyone's history file and pass it back to some sinister individual.
Oh that isn't a problem unless they look for the specific string 'mypassword' (or whatever). If they just grep for 'longname' then nothing can be determined from that. So... no biggy.
-DU-...etc...
     
foobars
Mac Elite
Join Date: Jan 2001
Location: Somewhere in the land surrouding Fenway Park
Status: Offline
Reply With Quote
Jul 12, 2004, 11:05 PM
 
Password found in swapfile - yes
Use the Password protected screensaver - no


Looks like its something else...
     
Tyre MacAdmin
Mac Elite
Join Date: Feb 2002
Status: Offline
Reply With Quote
Jul 13, 2004, 01:07 AM
 
Windows has a similar issue... here are two situations:

Swap file. Normal Windows operation can leave unencrypted text (including passwords) on your machine, in files you would never think to look in�but a hacker might. The first thing to do is to set your machine to clear the system paging file (swap file) at shutdown. Go to the Start menu and click on Run, type regedit, and click on OK. Go to HKEY_local_machine\system\currentcontrolset\contro l\ sessionmanager\memory management. Find or create the ClearPageFileAtShutdown Dword and make its value 1.

Dump file. A dump file stores data from memory during a system crash and can be helpful when diagnosing problems, but like a swap file, it can also expose a lot of sensitive, unencrypted data. To prevent Windows from creating the file, go to Control Panel | System. Click on the Advanced tab and then the Settings button on the Startup and Recovery pane. Set the drop-down menu under Write debugging information to (none). Similarly, the debugging program Dr. Watson saves information when applications crash. To disable it, go to HKEY_local_machine\software\Microsoft\WindowsNT\Cu rrentVersion\ AeDebug and set the Auto string to 0. Then use Windows Explorer to go to Documents and Settings\All Users\Shared Documents\DrWatson. Delete User.dmp and Drwtsn32.log, the insecure logs the program creates.

The only thing you can do is take precautionary steps in windows... personally I would hope this is cleared up in the next release... there is no logic in having these setting unsecured by default I hope Apple does the same.
     
ginoledesma
Mac Elite
Join Date: Apr 2000
Location: Los Angeles, CA
Status: Offline
Reply With Quote
Jul 13, 2004, 02:53 AM
 
A friend of mine pointed out where this can be a very big issue: Macs as servers. Although systems admins are the only ones with access to sudo and superuser privileges, I for one wouldn't want my fellow sysads to know my own personal password. After all, in some corporate environments, a user is assigned his/her own account and will be helf responsible for any action that that account is involved in.
     
Vax
Junior Member
Join Date: Oct 2001
Location: Osnabrueck, North Germany
Status: Offline
Reply With Quote
Jul 13, 2004, 07:54 AM
 
It seems to be an upgrade problem. Look at http://macslash.org/article.pl?sid=0...48&mode=thread.
--:: Insanity is also a state of mind ::--
     
Thain Esh Kelch
Mac Enthusiast
Join Date: May 2001
Location: Denmark
Status: Offline
Reply With Quote
Jul 13, 2004, 10:02 AM
 
I tried it on a Rev B iMac running 10.3.4, having 2 users.

Im an admin user and it showed up with both admin users passwords.. Scary...!

(Note to self: Remember this one to impress your friends)
     
danengel
Mac Enthusiast
Join Date: Oct 2000
Status: Offline
Reply With Quote
Jul 13, 2004, 04:27 PM
 
GPG (the GNU version of PGP) is very cautios. From 'man gpg':

On many systems this program should be installed as setuid(root). This
is necessary to lock memory pages. Locking memory pages prevents the
operating system from writing memory pages to disk. If you get no warn-
ing message about insecure memory your operating system supports lock-
ing without being root. The program drops root privileges as soon as
locked memory is allocated.
My idea: Locked pages are reserved for root, but the OS could give 1 page (=4 kB) to each application for secure stuff which will never be paged out and thoroughly deleted after use.
     
zigzag
Addicted to MacNN
Join Date: Aug 2000
Status: Offline
Reply With Quote
Jul 13, 2004, 06:54 PM
 
Question from an admitted neophyte: Does this have any bearing on encrypted disk images where the password is different from log-in and is not kept in Keychain? Thanks.
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Jul 13, 2004, 07:02 PM
 
Originally posted by Tyler McAdams:
Windows has a similar issue... here are two situations:

Swap file. Normal Windows operation can leave unencrypted text (including passwords) on your machine, in files you would never think to look in�but a hacker might. The first thing to do is to set your machine to clear the system paging file (swap file) at shutdown. Go to the Start menu and click on Run, type regedit, and click on OK. Go to HKEY_local_machine\system\currentcontrolset\contro l\ sessionmanager\memory management. Find or create the ClearPageFileAtShutdown Dword and make its value 1.

Dump file. A dump file stores data from memory during a system crash and can be helpful when diagnosing problems, but like a swap file, it can also expose a lot of sensitive, unencrypted data. To prevent Windows from creating the file, go to Control Panel | System. Click on the Advanced tab and then the Settings button on the Startup and Recovery pane. Set the drop-down menu under Write debugging information to (none). Similarly, the debugging program Dr. Watson saves information when applications crash. To disable it, go to HKEY_local_machine\software\Microsoft\WindowsNT\Cu rrentVersion\ AeDebug and set the Auto string to 0. Then use Windows Explorer to go to Documents and Settings\All Users\Shared Documents\DrWatson. Delete User.dmp and Drwtsn32.log, the insecure logs the program creates.

The only thing you can do is take precautionary steps in windows... personally I would hope this is cleared up in the next release... there is no logic in having these setting unsecured by default I hope Apple does the same.
In Windows, it's actually even worse. You can easily do a dump of RAM as a non-admin user in Windows. Doesn't even need to be in swap. Of course any file that's encrypted on disk is not encrypted in RAM, making it easy to access if you've got login access to the Windows machine.
     
Tyre MacAdmin
Mac Elite
Join Date: Feb 2002
Status: Offline
Reply With Quote
Jul 14, 2004, 12:50 AM
 
Originally posted by Brass:
In Windows, it's actually even worse. You can easily do a dump of RAM as a non-admin user in Windows. Doesn't even need to be in swap. Of course any file that's encrypted on disk is not encrypted in RAM, making it easy to access if you've got login access to the Windows machine.
And how exactly, out of curiosity, would you go about accessing that? Ram is cleared at shutdown and if you have just a logon prompt I'm not sure how you could get access...?
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 14, 2004, 02:40 AM
 
Originally posted by Tyler McAdams:
And how exactly, out of curiosity, would you go about accessing that? Ram is cleared at shutdown and if you have just a logon prompt I'm not sure how you could get access...?
A 'dump' of something implies saving this something to disk. And having login access presumably means you have an user and can log in.
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Jul 14, 2004, 02:56 AM
 
Originally posted by Tyler McAdams:
And how exactly, out of curiosity, would you go about accessing that? Ram is cleared at shutdown and if you have just a logon prompt I'm not sure how you could get access...?
I think he meant "login access" as opposed to just physical access — you are able to log in to the system.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
Tyre MacAdmin
Mac Elite
Join Date: Feb 2002
Status: Offline
Reply With Quote
Jul 14, 2004, 05:54 AM
 
Right but why would the admin password be in ram... if you logged on with your user acct?
     
entrox
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status: Offline
Reply With Quote
Jul 14, 2004, 07:19 AM
 
Originally posted by Tyler McAdams:
Right but why would the admin password be in ram... if you logged on with your user acct?
Well, that's the 64.000� question!
     
Tyre MacAdmin
Mac Elite
Join Date: Feb 2002
Status: Offline
Reply With Quote
Jul 14, 2004, 08:49 AM
 
Originally posted by entrox:
Well, that's the 64.000� question!
Killer... I've never seen a euro!

I'm still not buying it w/o an explanation... No empircal data... no consistant repetable method and the answer is no... I'm a hard ass about that sh!t. I can't stand somebody who says "because". That's kindergarden. Now, I'm not saying that's what he said bf I get flamed here... I'm saying I hate it when it happens... big diff
     
Moose
Senior User
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 14, 2004, 09:46 AM
 
Originally posted by danengel:
My idea: Locked pages are reserved for root, but the OS could give 1 page (=4 kB) to each application for secure stuff which will never be paged out and thoroughly deleted after use.
My understanding of how RAM works is that you'd only need to overwrite it once. I'd be more than happy for any EEs to kick my ass on this point, though.
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 14, 2004, 04:04 PM
 
Originally posted by Tyler McAdams:
Right but why would the admin password be in ram... if you logged on with your user acct?
Because... many, if not most, Macs are single user machines. This is especially true in the case of laptops. For many, if not most, multiuser Macs... and for the single user Macs the user that uses the system most is also usually the admin user. Even if that machine is setup with a separate admin account.... most primary users of Macs also allow themselves to admin the machine.

That means... when joemacuser is using the machine he can just type his own password again when prompted to make changes. He can 'sudo adminsomething' and type in his own password and it will allow him to do the 'adminsomething'.

That means that joemacusers password may not be the same as the admin user (if there is a separate one) BUT joemacusers password is an admin password. That is to say, joemacuser is a member of the admin group (gid=80). If you get joemacusers password then you can log in as joemacuser (or 'su joemacuser') and then you can also have admin rights on that Mac.

This is the natural, default, recommended, easy-to-use, convenient, most common way to use Macs. So that is why it is very likely that AN admin users password is in RAM on any given Mac.
-DU-...etc...
     
absmiths
Mac Elite
Join Date: Sep 2000
Location: Edmond, OK USA
Status: Offline
Reply With Quote
Jul 14, 2004, 04:16 PM
 
Originally posted by utidjian:
Because... many, if not most, Macs are single user machines.
That's very interesting - except that he was talking about WINDOWS.
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 14, 2004, 04:34 PM
 
Originally posted by absmiths:
That's very interesting - except that he was talking about WINDOWS.
Ditto (for the most part).
-DU-...etc...
     
Tyre MacAdmin
Mac Elite
Join Date: Feb 2002
Status: Offline
Reply With Quote
Jul 14, 2004, 05:52 PM
 
Yeah that was windows I was talking about...
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Jul 14, 2004, 08:17 PM
 
Originally posted by Tyler McAdams:
And how exactly, out of curiosity, would you go about accessing that? Ram is cleared at shutdown and if you have just a logon prompt I'm not sure how you could get access...?
Sorry, my post was a bit misleading. You do actually need physical access to the Windows machine. But you don't need admin access to get a complete dump of RAM to disk. You just press CTRL/ScrollLock twice (although I believe it can be disabled, it's on by default). This will dump the entire contents of RAM to easily accessible files on disk. Note that any encrypted files/directories are unencrypted while in RAM, so the encryption is not of much value for this type of malicious behaviour.

But I'm getting off topic (as I often do). The above is for Windows, and we're worried about Macs here

Did I mention that I found 6 instances of my password in the Solaris swapfiles here?
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jul 15, 2004, 08:23 AM
 
Originally posted by Brass:
Did I mention that I found 6 instances of my password in the Solaris swapfiles here?
Was this due to Solaris software or third party apps?
-DU-...etc...
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Jul 15, 2004, 10:30 AM
 
Originally posted by Moose:
My understanding of how RAM works is that you'd only need to overwrite it once. I'd be more than happy for any EEs to kick my ass on this point, though.
Overwriting it once will be enough to keep that machine from accessing its contents. Intelligence agencies have been making some rather impressive strides in this field, though, and the stuff that they can do with formatted hard drives is nothing short of astounding.

Then again, if an intelligence agency is after you, it could be argued that you have bigger things to worry about.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Evinyatar
Mac Enthusiast
Join Date: May 2000
Location: Belgium
Status: Offline
Reply With Quote
Jul 15, 2004, 11:47 AM
 
For those where the password doesn't show up, try replacing 'longname' with your actual password. That should at least tell us if it's in there at all (albeit not in the vicinity of the 'longname' string).
PowerMac G4 400MHz/832MB/60GB
AlBook G4 15" 1.25GHz/1.5GB/60GB
Athlon 64 3500+/Asus A8N-SLI Premium/2GB RAM/990GB HD/GF7800GT 512
     
Tyre MacAdmin
Mac Elite
Join Date: Feb 2002
Status: Offline
Reply With Quote
Jul 15, 2004, 04:54 PM
 
Originally posted by Brass:
You just press CTRL/ScrollLock twice (although I believe it can be disabled, it's on by default). This will dump the entire contents of RAM to easily accessible files on disk.
Ok... i hit ctrl scroll lock twice... where is the data supposed to be dumped to?

Also, if this can be disabled where do you disable it... what registry setting?

Sorry... I need to know this info... I'll call it now a complete highjack...
     
Geobunny
Mac Elite
Join Date: Oct 2000
Location: Edinburgh, Scotland
Status: Offline
Reply With Quote
Jul 15, 2004, 08:04 PM
 
Originally posted by Evinyatar:
For those where the password doesn't show up, try replacing 'longname' with your actual password. That should at least tell us if it's in there at all (albeit not in the vicinity of the 'longname' string).
Please don't put your entire password in as the search string. Instead, use a consecutive series of characters that are unlikely to exist within a word, that way you'll not be adding your password to the swap file as soon as you execute the command.

BTW Mike Bombich, if you're following this thread (don't even know if you read MacNN), please rise, put your right hand in the air and scream "I'm guilty!". CarbonCopyCloner puts the admin password onto the command line and through a pipe in clear text. I found this by using 'sudo' itself as the grep search string ie sudo strings -8 /var/vm/swapfile* | grep -A 4 -i sudo. When you use CCC, it uses its own method of obtaining admin privs, rather than using Apple's secure(?) method.

Here's a line of output from when I performed that search above:
Code:
echo 'MY_PASS_WAS_HERE' | sudo -p "" -S /usr/bin/ditto -rsrcFork /'Library' '/Volumes/Phoenix/''Library'
As you can see, CCC echos the user password to the command line, and pipes in as input to sudo!! I suspect CCC is NOT the only application doing this sort of jiggery pokery and may explain why not all of us are finding our passwords in the swapfiles.

About a week ago, I ran CCC under my own username (regular admin user) and when that failed for various reasons, I enabled the root account and ran it from there too. Both passwords showed up. Please note that my computer HAS since been restarted!

If others can maybe try grepping for the "sudo" command, and hopefully recognise the output, we may be able to pinpoint the culprits. I very much doubt it's something Apple's doing wrongly.
ClamXav - the free virus scanner for Mac OS X | Geobunny learns to fly
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Jul 15, 2004, 08:48 PM
 
Originally posted by utidjian:
Was this due to Solaris software or third party apps?
I don't use any 3rd party software on Solaris - it's merely a workstation. Certainly none which would use my login password for anything.
     
VValdo  (op)
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 15, 2004, 11:11 PM
 
Originally posted by Geobunny:
BTW Mike Bombich, if you're following this thread (don't even know if you read MacNN), please rise, put your right hand in the air and scream "I'm guilty!". CarbonCopyCloner puts the admin password onto the command line and through a pipe in clear text\
Did you CC this to Bombich in an email?

Anyone else discovering their passwords in other apps?

W

PS-- Has there been any official response to this from Apple? I sent a report to http://www.apple.com/macosx/feedback but sometimes I think it's routed to /dev/null. Sigh.
     
Moose
Senior User
Join Date: May 2001
Status: Offline
Reply With Quote
Jul 16, 2004, 08:35 AM
 
Originally posted by Millennium:
Overwriting it once will be enough to keep that machine from accessing its contents. Intelligence agencies have been making some rather impressive strides in this field, though, and the stuff that they can do with formatted hard drives is nothing short of astounding.

Then again, if an intelligence agency is after you, it could be argued that you have bigger things to worry about.
Okay, you realized I was talking about RAM and not a hard drive, right?
     
 
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 10:38 PM.
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.,