Ssh is only taken as a sample of code that prevents password theft from ram, not for actual ssh connections.

The modifications would be just additional code that uses the password as a passphrase to mount selected truecrypt-clone containers, probably by calling the CLI of the truecrypt clone using the C system() call.

Or modify the truecrypt clone sources instead. They'd have protection against ptrace would they not?

Could use a separate original instance of ssh for ssh connections if wanted.

You just broke your security.

The system() is not a secure library function. It permits side effects as it has to use bash to interpret the actual command - and that, at a minimum, exposes your password on the command line, or to debugging attached to the shell. Also see side effects - bash also interprets any special characters that may be in the command string.

ssh already supports multiple connections (see port forwarding).

Surely attaching to a shell that lives for a few milliseconds must be a challenge. What do you mean by special characters in the command string?

The simple things - ()*`';|$ And there are more. As for "that lives for a few milliseconds"?

Security is not a state - it is a process of doing things and paying attention to the details. ANY thing that can expose a secret is exposing that secret. And just how long does it take when something hangs for a while? Or what happens if an error occurs? Or what happens if something simple like a file name with rm -rf * occurs? Or one with a file name like "printenv >/tmp/public_file", or files with blanks embedded (ran across one using authors names - wasn't a problem for years, until there was a chinese name like fāng'àn... Handling special characters is NOT a simple process, and isn't static.) And since system() is using a shell, WHICH shell? Solaris/AIX/Linux don't all use the same one, and then there is Windows.

http://xkcd.com/327/

There is also the issue of systems that track process (pacct records, audit records,...) some will record every parameter.... and thus record any passwords that happen to be on the command line.

The system() function (along with popen, printf, sprintf, ...) are not secure library functions.

Are you talking about invalid arguments in the ssh command line?

Invalid arguments in system() cannot appear because they are hardcoded in the C source code in my usage, except the password/passphrase. Any special characters in the passphrase are trivial to check and say "Sorry, passphrase must only contain letters a-z, A-Z or digits 0-9."

For absolute security, it could be a direct call to the truecrypt-like software's main() function if the sources are build into one.

You should also consider what happens to the password when the script stops running. It is still in RAM and can be found by scanning RAM for it.

Here's an idea. Have a password file inside an encrypted container. All you need to do is mount this container and use the password file inside for opening any further containers. That way you put the password only once and it isn't stored in RAM.

Yes.
You think so? the shell is a very powerful tool - and it can import things that will change how the command is interpreted. Things like line termination, parameter separation, even .bashrc... which can contain any number of commands.

And limiting the passphrase in that manner makes it easier to hack. Passwords SHOULD have a character set as large as possible. It makes for much stronger passwords.

At which point you are rewriting the entire truecrypt-like program to be a function, and NOT using the system() library function.

Note, you are now expanding the scope of ssh - and making it harder to validate.

It is already hard enough as it is.

Besides, you could use fork/exec yourself and set the parameters how you like - and completely bypass the shell entirely. Though that doesn't prevent the exposure of a password in the applications parameter list, or possibly through the application environment. It is still possible to also substitute a different program. Consider what might happen within a chroot jail - what it puts as the program name can be anything.

And yes - this is stretching. But you do have to consider all the places and things that ssh is being used now.

Looks like preventing theft of a password from ram is hopeless against malware with root privileges. Only normal user malware can be prevented from stealing a password. And even that with a lot of precaution.

Would a truecrypt clone use the same tricks as ssh against ptrace? Is this trick a common practise in security software?

Should, but normally isn't done. It makes debugging very difficult. One reference for disabling ptrace outside of programming tricks is at http://fedoraproject.org/wiki/Featur...inuxDenyPtrace.

Though this is about cross security domain blocks, the capability to disable ptrace is in the system.

There is some software in the windows world that allows you to automatically enter passwords to forms and other places.

How would the linux equivalent protect against theft of passwords from ram?

When firefox stores passwords, how does it ensure they cannot be stolen from ram?

Windows doesn't protect against the theft.
It doesn't.

1. only the owner (and root) may access the memory.
2. all other processes are blocked.

As I have said earlier, it is possible for SELinux security labels to define a compartment that even root cannot access. But it is a bit tricky to setup, but once setup is very easy to use.

Yes, the answer is "it doesn't". That is waaaay beyond the standard of due diligence that anyone's actually expected to do.

I think it's worth pointing out that any malware capable of doing that would have to have been written specifically to target a single specific version of Firefox.

Also: I did a quick Amazon search for related material, and this one certainly looks relevant: http://www.amazon.ca/dp/1118825098

Finally, I'd recommend approaching this from the reverse angle. In order to answer "how would I prevent malware from stealing passwords from RAM" (and evaluate the risk of that actually happening), you first need to answer: "how would I write malware that steals passwords from RAM?"

1 members found this post helpful.

That is the right question.

You realize that the malware that would most likely be used to steal that password is a keylogger, right?