[utidjian]

Originally posted by Brass:
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.

Interesting... that implies that the mere act of logging on to the system stores your plaintext password in at least 6 places.

What command did you use for grepping your password from the Solaris system?

What version and patchlevel of Solaris are you using?

I ask because I have quite a few Sun boxes around here.

[utidjian]

Originally posted by Geobunny:
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.

It will not add it to the swap file as soon as the command is executed. It is near impossible to predict exactly when a page of RAM is swapped. It will put the command, including the search string, into the ~/.bash_history file. If anyone is fiddling with comandline searches and using their password in plain text as a search string they should edit or delete their .bash_history file. It would be an extremely unusual circumstance for a command line buffer to be swapped while that command is actually running.

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.

It does not echo your password to the commandline. You can verify this by looking in your .bash_history file for that command. The part of CCC you found swapped is part of a script. Since CCC tends to run for a long time that part of the programs memory space happened to get swapped out.

The reason why everyone is not finding passwords in swapfiles is two fold.
First. The application (and this includes loginwindow.app) has to ask for the users password. The app gets the password either from the user keying it in on the keyboard, from a file where that password is stored (possibly something like ~/.fetchmailrc), from its own (possibly encrypted) cache of passwords (mozilla), or from the Keychain.app. Whatever mechanism it uses to retrieve the password it is then passed to the application in plaintext. The application puts the password string into a buffer in memory (it gets written to RAM) at least once. ALL programs that use some sort of password must do this at least once however briefly. ANY program that requires a password will do this even if it doesn't ask the user directly. Even after the particular program is finished using the password for whatever authentication and/or authorization it needs it may still leave the that plaintext password in RAM. Even after the particular program is finished running and has exited (or when you close the app) the plaintext password may still be in RAM for some time.... seconds, minutes, hours, weeks. It all depends on how much RAM you have, how the VM system works, and when the area of RAM where the password was stored gets overwritten with something else.

Second. At some point... depending on the amount of RAM you have, when a particular program was started, when it was last used, the systems memory load (other apps needing RAM), and possibly other factors, the particular area of RAM where the plaintext password was stored MAY get swapped out to the swapfile. There is no easy way to predict when (or even if) this will happen.

There is at least one way to ensure that the buffer that is holding the password is never swapped out by using mlock(). But there are issues with using mlock() because then any program that uses passwords and uses mlock() to prevent them from being swapped out also has to run as setuid or setgid root. For something like CCC or loginwindow.app it would make sense to run as setuid or setgid root but certainly not for a web browser or email client.

For Mike Bombich to fix CCC it would require some careful rewriting of the application. It would be simpler if CCC requested a reboot after being run (which is what you did) and what people should do until it is fixed.

It is completely impractical to require that people reboot after using every single application that may use a password. Because loginwindow.app is one of the 'culprits' it would require one to reboot immediately after loggin in!

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.

I have also run some tests. I am convinced (to my satisfaction) that loginwindow.app is one of the 'cuplrits'. The way I did my tests was to try and ensure that the only application that got my password in plain text was the loginwindow.app, then load the machine to force it to start swapping heavily, then start grepping. I got my password once. I may have made a mistake somewhere but I don't think so. I don't know how reliable it is to pinpoint the offending app by just looking at the context in which the plaintext password appears. In the results you show however if that string is from running CCC then CCC is certainly one of the 'culprits'.

There may be many applications that allow the plain text password to be swapped out. At least CCC and loginwindow.app are suspect. As has been mentioned already even if Apple was to fix all of its applications there is still the problem of third party apps. Seems that all we can do at the moment for closed source apps is keep looking and when we find apps that swap out the plain text password complain to the app provider until they fix it. For applications that are open source we can audit them to see if plain text passwords are handled correctly, fix the source if not, send the patchfile to the author.

[Geobunny]

Originally posted by utidjian:
It will not add it to the swap file as soon as the command is executed. It is near impossible to predict exactly when a page of RAM is swapped. It will put the command, including the search string, into the ~/.bash_history file. If anyone is fiddling with comandline searches and using their password in plain text as a search string they should edit or delete their .bash_history file. It would be an extremely unusual circumstance for a command line buffer to be swapped while that command is actually running.

Ok no, not immediately, but if you do it often enough and your computer is doing other stuff at the same time (or you have to go away for a while and decide to try it again later), there's a good chance that it'll have been swapped out to disk. What I was suggesting was merely a way of ensuring your entire password doesn't get swapped out in clear text as a result of these tests.

It does not echo your password to the commandline. You can verify this by looking in your .bash_history file for that command.

Actually, it does echo it on the command line, but not TO the command line shell which is why it's not showing up in the shell history (.tcsh_history or .bash_history, whichever shell you decide to use). Commands will only show up in that history if you have physically typed them yourself. I can easily understand why Bombich took that route to gaining admin privileges, have you looked at Apple's documentation for doing it properly?! Admittedly I've not looked at it recently and it may have since been updated, but certainly the last time I looked at it, it was rather unhelpful!

The part of CCC you found swapped is part of a script. Since CCC tends to run for a long time that part of the programs memory space happened to get swapped out.

Be that as it may, whether it's true or not it still doesn't alter the fact that CCC's storing the password in clear text in RAM and passing it through pipes on the command line, both of which I would say are bad. Given that CCC is a very time consuming program though, I can't think how else it could keep the admin privs long enough to carry out each task, but System Prefs manages, so it must be possible.

/off to look for the authentication API...

[CharlesS]

The problem with Carbon Copy Cloner is that it is written with AppleScript Studio. I don't think that there's an AppleScript API for the Security Framework, so the only way to launch stuff as root from ASS is to pass the password to sudo via standard input.

[Angus_D]

Gah. That's just plain bad.

[VValdo]

<i>I can easily understand why Bombich took that route to gaining admin privileges, have you looked at Apple's documentation for doing it properly?! Admittedly I've not looked at it recently and it may have since been updated, but certainly the last time I looked at it, it was rather unhelpful!</i>

Here's some C code from Apple as well. Not too clear.

I'm not really a programmer but here's where I found how to do it, a long time ago. This is an old document, but it might be helpful.

I also found this project to create a cocoa framework to deal with the keychain. I bet this will be more useful. There used to be another cocoa object that let you do authorization, but i can't find it.

W

[CharlesS]

Yeah, of course there's a C API. But the point is that CCC is written in AppleScript Studio, and to the best of my knowledge there's no AppleScript API.

[Brass]

Originally posted by utidjian:
Interesting... that implies that the mere act of logging on to the system stores your plaintext password in at least 6 places.

What command did you use for grepping your password from the Solaris system?

What version and patchlevel of Solaris are you using?

I ask because I have quite a few Sun boxes around here.

Using Solaris 9.

I've also ssh'd to a zillion other boxes from here, and all sorts of other admin activity... not just logging in necessarily.

Note that I grepped for a sequence of two characters from the password itself (it's the only way to be sure of finding every occurrance, and doesn't add the password to swap itself - although it does find a few other irrelevant bits of info).

Ie,

su -
cd /swap
strings ./* | grep <char1><char2>

[utidjian]

Originally posted by Brass:
Using Solaris 9.

I've also ssh'd to a zillion other boxes from here, and all sorts of other admin activity... not just logging in necessarily.

Note that I grepped for a sequence of two characters from the password itself (it's the only way to be sure of finding every occurrance, and doesn't add the password to swap itself - although it does find a few other irrelevant bits of info).

Ie,

su -
cd /swap
strings ./* | grep <char1><char2>

Interesting.... thanks. I tried it on the 35 Sun/Solaris servers I have access to and got the root password on one of them. My root passwords seem to have character combinations that occur very frequently in the "noise" of my swap partitions. I cuold not find a reliable or consistent context keyword that would also yield the password when using, for example, 'grep -A 16' or 'grep -B 16'. It seems that on Solaris one needs to know at least part of the password beforehand.... really all of the password in order to recognize it in the "noise". This is not to say that it will never be a problem on Solaris, it is not to say that there is no reliable context word that will yield an unknown password (perhaps I just didn't discover one), and it is to say that I think that any password on any system should not appear in any file or partition in plain text. Also note I tried this on servers, not workstations.

I also tried a similar search on some Linux systems (workstations and servers), like this:

Code:
cat /dev/<swap partition> | strings | grep <char1><char2>

(and variations). The results were similar to the Solaris systems.

The main difference I can see between the problem in Mac OS X and Solaris and Linux is that, in the case of Solaris and Linux one needs to know at least part of the password already and be able to distinguish it from the "noise". By "noise" I mean results that have the same two search characters but are not passwords. In the case of Mac OS X there is a simple context word ('longname') that may yield the password in some cases.

In any case... I feel it is a still a problem for all systems and that it should be fixed. The "fixing" part is not going to be easy though.

[Brass]

Originally posted by utidjian:
Interesting.... thanks. I tried it on the 35 Sun/Solaris servers I have access to and got the root password on one of them. My root passwords seem to have character combinations that occur very frequently in the "noise" of my swap partitions. I cuold not find a reliable or consistent context keyword that would also yield the password when using, for example, 'grep -A 16' or 'grep -B 16'. It seems that on Solaris one needs to know at least part of the password beforehand.... really all of the password in order to recognize it in the "noise". This is not to say that it will never be a problem on Solaris, it is not to say that there is no reliable context word that will yield an unknown password (perhaps I just didn't discover one), and it is to say that I think that any password on any system should not appear in any file or partition in plain text. Also note I tried this on servers, not workstations.

I also tried a similar search on some Linux systems (workstations and servers), like this:

Code:
cat /dev/<swap partition> | strings | grep <char1><char2>

(and variations). The results were similar to the Solaris systems.

The main difference I can see between the problem in Mac OS X and Solaris and Linux is that, in the case of Solaris and Linux one needs to know at least part of the password already and be able to distinguish it from the "noise". By "noise" I mean results that have the same two search characters but are not passwords. In the case of Mac OS X there is a simple context word ('longname') that may yield the password in some cases.

In any case... I feel it is a still a problem for all systems and that it should be fixed. The "fixing" part is not going to be easy though.

I suspect that if you searched for sequences of characters that included only [a-z][A-Z][0-9] characters, and were less than say 15 characters, you'd end up with a great list of possible passwords to try.

[Moonray]

If your password is shorter than 8 characters you have of course to change the -8 of the command in the fist post of this thread to something with a lower number to get it shown.

-

[utidjian]

Originally posted by Brass:
I suspect that if you searched for sequences of characters that included only [a-z][A-Z][0-9] characters, and were less than say 15 characters, you'd end up with a great list of possible passwords to try.

Problem with that is... I get anywhere from about 300,000 to several million results in the list. If all one has is the data from the swapfile/partition it will not be very useful. One would have to try and crack the account(s) repeatedly... this might take, on average, anywhere from about 100,000 attempts to millions of attempts. Someone would most likely notice that many unsuccessful login attempts. I know I would!

If one has access to the disk and can get the shadow password data then it would be far more effective to run something like John the Ripper on the shadow passwords.

[h00ligan]

well what about these 2 possible solutions

#1 redirect the swap file to the encrypted home folder

#2 create a ramdisk at boot and redirect the swap file to that?

just wondering.. very interesting conversation and yes i do see it as a hole. If someone gets physical access to your machine, it would be nice to know that short of tons of time and money you are pretty well safe. That is obviously NOT the case here.

my powerbook gets stolen in sleep mode

they pull the battery, boot it to firewire target disk mode..

execute on their local machine the command listed in teh first post.. et voila...compromised.

[chabig]

Redirecting a virtual memory swap file to a RAM disk would be an abomination of the worst kind. The purpose of virtual memory is to make the address space larger than physical RAM.

Chris

[h00ligan]

understandable.. however, if you have so much ram you never page.. say like 2 gigs for surfing the web and emailing... then what difference does it make.

The onlyproblem with turning off the page file ist hat apps are going to complain about it (photoshop).

Any feedback on the other idea of redirecting it to the user's encrypted home folder... would that work?

[chabig]

I don't know enough to say if redirecting to an encrypted file is possible, but I imagine you would suffer a performance hit from it.

Chris

[h00ligan]

Originally posted by chabig:
I don't know enough to say if redirecting to an encrypted file is possible, but I imagine you would suffer a performance hit from it.

Chris

i'd agree with that but for the fact i shouldn't be paging jack since i have way more ram then i use.

just a thought.

[jamesa]

edit: forget it

I think it may have something to do with having the keychain unlocked...

-- james

[Geobunny]

If you page out to an encrypted home folder, what do other people using your computer with different home folders do? Your folder can't remain unencrypted the whole time, kinda defeats the purpose!

Ditto while your computer's starting up, it can't access the encrypted folder to gain access to the swap space, so probably wouldn't even start up!

[JKT]

Appleinsider has a screenshot showing a new Security preference in Tiger for encrypting memory swapped to the disk - I suspect that this is to prevent the issue reported in this thread?