LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Can malware steal a password held in ram by a running process? (https://www.linuxquestions.org/questions/linux-security-4/can-malware-steal-a-password-held-in-ram-by-a-running-process-4175529812/)

Ulysses_ 01-02-2015 11:33 AM

Can malware steal a password held in ram by a running process?
 
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?

jpollard 01-02-2015 11:51 AM

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.

Ulysses_ 01-02-2015 12:26 PM

Quote:

Originally Posted by jpollard (Post 5294170)
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)

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

schneidz 01-02-2015 12:33 PM

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

[schneidz@hyper public_html]$ cat ulysses.ksh
#!/bin/bash

read -s -p "enter username:" un; echo
read -s -p "enter password:" pw; echo
export un
while [ 1 ]
do
echo un = $un -- pw = $pw
sleep 5
done
[schneidz@hyper public_html]$ ./ulysses.ksh
enter username:
enter password:
un = hello -- pw = world
...

Code:

[schneidz@hyper ~]$ echo un = $un -- pw = $pw
un = -- pw =

?

veerain 01-02-2015 01:18 PM

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.

Ulysses_ 01-02-2015 01:27 PM

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.

rknichols 01-02-2015 01:58 PM

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:
Code:

dmsetup table --showkeys {device_name}

Ulysses_ 01-02-2015 02:16 PM

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?

jpollard 01-02-2015 05:30 PM

Quote:

Originally Posted by Ulysses_ (Post 5294202)
Is the trick used by ssh easy to explain in "layman" terms?

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.

Ulysses_ 01-03-2015 09:43 AM

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.

jpollard 01-03-2015 11:24 AM

Quote:

Originally Posted by Ulysses_ (Post 5294690)
Probably wiser to build ssh with my modifications then.

ssh should already have this protection.

Quote:

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.
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.

Ulysses_ 01-03-2015 12:35 PM

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.

jpollard 01-03-2015 08:35 PM

No.

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

sundialsvcs 01-03-2015 10:31 PM

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.

jpollard 01-04-2015 12:29 AM

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


All times are GMT -5. The time now is 11:44 AM.