Let's say a script prompts for a password and then uses the password to open an encrypted container or login to somewhere remotely or whatever.

If the script keeps the password in ram while it's looping doing whatever its purpose is, can NON-root malware steal the password?

It depends on where the malware is, and how the password is being used.

1. passwords in shell scripts depend on how you use them. If they are put on the commandline, (like "mysql --user=user_name --password=your_password db_name" then they are public to anyone using the ps command for the duration of the command. Now there have been tricks to try and hide it (things like changing the parameter with the password), but they don't work reliably, and the password is STILL exposed for a short time.

2. if the malware is running as the same user (or root), then it is possible to use the debugger to extract it. There are some tricks available to block that (ssh uses one), and if your system supports SELinux, I think there is one there (it disables the capability for a ptrace connection to the process).

3. If the password is embedded in the script (rather than being prompted for) you also have to prevent the script from being read - as just reading the script will expose the password. The problem is that if a different user is going to use the script, then it must be readable by that user as well...

In general, passwords and scripts don't mix very well.

1 members found this post helpful.

Is the trick used by ssh easy to explain in "layman" terms?

i'm running this test but i am not able to find out how to read the password in another terminal instance:?

You can read the reads /writes of a process using strace if you are same user of process or the root user can read it all.

The plan being considered here is to only type the password before any malware is covertly loaded, and ensure this by using a live CD and blocking all internet access until the password is typed.

A login password does not need to be recorded anywhere, so unless some program along the way is retaining a copy in its memory the password could not be later recovered. Encryption keys are another matter. The key (not the passphrase, but the key generated from or unlocked by the passphrase) must be kept in kernel memory so that data can be encrypted/decrypted when required. For Linux whole disk encryption, root can easily recover such a key:

I need the passphrase in ram at all times, any key stolen is not much of an issue (because it only decrypts one container).

How can one prevent the passphrase from being stolen using something like ssh's tricks mentioned above?

The trick is fairly simple, but can be tricky to implement. What it basically does is use the ptrace system call to ptrace itself.

What makes it tricky as far as scripting goes, is that it would have to be done within the interpreter program itself, and not by the script. Doing it outside the interpreter becomes a race condition - though if you lose the race, you can detect it as the ptrace system call will fail.

It happens to work because the kernel only allows one process to control another process through the ptrace system call. You can test this by using gdb to attach to a shell process, and then attempt to do it again while gdb is active. The second should fail.

As an added note: this would also block strace - which uses the ptrace system call to get the information from the traced process.

1 members found this post helpful.

Probably wiser to build ssh with my modifications then.

Also disabling the swap space is another thought. Or is ssh's code protected against this too? Truecrypt's keys can be recovered from the swap space sometimes.

ssh should already have this protection.

root can always dump memory. But outside of root, there isn't that much of a problem unless you use hibernation. At that point the memory is copied to swap to make it fast to recover... and that also means that physical access can be used to remove the swap device an plug it elsewhere. You could use encrypted swap though.

But malware running on the system would tend to not have access unless it is running as root.

If root dumps memory, does obfuscating the passphrase's storage in ram and the source code have any chance? The attacker does not have the source code of my modifed ssh that is source modified to also manage 100 encrypted containers.

No.

Most likely your "modifications" will break ssh protocol standards, or violate security.

Of course, step one is to make sure that the ssh connection is secured by digital certificates, each one of which might be password-protected.

After all, when you walk into the upper floors of any office-building, there's no one standing there asking each person, "say the magic word!" No, that person must present a unique badge, and if necessary, enter a PIN-number that's associated with it. The PIN unlocks the badge but is useless with regard to any other badge and is equally useless without the badge to which it belongs. If the badge is reported lost or stolen, within minutes it is useless ... PIN or not.

Furthermore, in a true security system, this should serve only for authentication. The access authorizations that are granted to a particular certificate (security-token ... badge ...) are not in any way encoded in the certificate itself and cannot be affected in any way by the certificate-holder.

Just a nit, but that PIN is the password. The "unique badge" is the login name.