|
|
Finding admin password in the swapfile... (Page 2)
|
|
|
|
Junior Member
Join Date: Jan 2004
Location: Call off the search.
Status:
Offline
|
|
|
the navajo know
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2001
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jun 2002
Location: UK
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Grizzled Veteran
Join Date: Jul 2001
Location: Sydney, Australia
Status:
Offline
|
|
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?
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Apr 1999
Location: Copenhagen, Denmark
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Jan 2001
Location: The Sar Chasm
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Mar 2000
Location: Allston, MA, USA
Status:
Offline
|
|
|
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: Jul 2002
Location: London, UK
Status:
Offline
|
|
Password found in swapfile - yes
Use the Password protected screensaver - yes
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: Nov 2003
Location: Amsterdam
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
Ambrosia - el Presidente
Join Date: Sep 2000
Location: Rochester, NY
Status:
Offline
|
|
Originally posted by JKT:
Password found in swapfile - yes
Use the Password protected screensaver - yes
No
Yes
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Grizzled Veteran
Join Date: Oct 2003
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2002
Location: NYC
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2001
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
Forum Regular
Join Date: Mar 2001
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2001
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Jan 2001
Location: Somewhere in the land surrouding Fenway Park
Status:
Offline
|
|
Password found in swapfile - yes
Use the Password protected screensaver - no
Looks like its something else...
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Feb 2002
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Apr 2000
Location: Los Angeles, CA
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Junior Member
Join Date: Oct 2001
Location: Osnabrueck, North Germany
Status:
Offline
|
|
|
--:: Insanity is also a state of mind ::--
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: May 2001
Location: Denmark
Status:
Offline
|
|
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)
|
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: Oct 2000
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2000
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Feb 2002
Status:
Offline
|
|
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...?
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
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'."
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Feb 2002
Status:
Offline
|
|
Right but why would the admin password be in ram... if you logged on with your user acct?
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2003
Location: Stuttgart, Germany
Status:
Offline
|
|
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!
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Feb 2002
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Senior User
Join Date: May 2001
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Sep 2000
Location: Edmond, OK USA
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
Originally posted by absmiths:
That's very interesting - except that he was talking about WINDOWS.
Ditto (for the most part).
|
-DU-...etc...
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Feb 2002
Status:
Offline
|
|
Yeah that was windows I was talking about...
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
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?
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
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!
|
|
|
|
|
|
|
|
Mac Enthusiast
Join Date: May 2000
Location: Belgium
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Feb 2002
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Oct 2000
Location: Edinburgh, Scotland
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2001
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: May 2001
Status:
Offline
|
|
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?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|