LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 01-02-2015, 10:33 AM   #1
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,158

Rep: Reputation: 45
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?
 
Old 01-02-2015, 10:51 AM   #2
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,842

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
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.

Last edited by jpollard; 01-02-2015 at 10:55 AM.
 
1 members found this post helpful.
Old 01-02-2015, 11:26 AM   #3
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,158

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by jpollard View Post
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?
 
Old 01-02-2015, 11:33 AM   #4
schneidz
LQ Guru
 
Registered: May 2005
Location: boston, usa
Distribution: fc-15/ fc-20-live-usb/ aix
Posts: 5,258

Rep: Reputation: 914Reputation: 914Reputation: 914Reputation: 914Reputation: 914Reputation: 914Reputation: 914Reputation: 914
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 =
?
 
Old 01-02-2015, 12:18 PM   #5
veerain
Senior Member
 
Registered: Mar 2005
Location: Earth bound to Helios
Distribution: Custom
Posts: 2,524

Rep: Reputation: 319Reputation: 319Reputation: 319Reputation: 319
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.
 
Old 01-02-2015, 12:27 PM   #6
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,158

Original Poster
Rep: Reputation: 45
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.

Last edited by Ulysses_; 01-02-2015 at 12:48 PM.
 
Old 01-02-2015, 12:58 PM   #7
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,276

Rep: Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945
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}
 
Old 01-02-2015, 01:16 PM   #8
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,158

Original Poster
Rep: Reputation: 45
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?

Last edited by Ulysses_; 01-02-2015 at 03:40 PM.
 
Old 01-02-2015, 04:30 PM   #9
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,842

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
Quote:
Originally Posted by Ulysses_ View Post
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.

Last edited by jpollard; 01-02-2015 at 04:33 PM.
 
1 members found this post helpful.
Old 01-03-2015, 08:43 AM   #10
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,158

Original Poster
Rep: Reputation: 45
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.
 
Old 01-03-2015, 10:24 AM   #11
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,842

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
Quote:
Originally Posted by Ulysses_ View Post
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.
 
Old 01-03-2015, 11:35 AM   #12
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,158

Original Poster
Rep: Reputation: 45
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.

Last edited by Ulysses_; 01-03-2015 at 11:46 AM.
 
Old 01-03-2015, 07:35 PM   #13
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,842

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
No.

Most likely your "modifications" will break ssh protocol standards, or violate security.
 
Old 01-03-2015, 09:31 PM   #14
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176
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.
 
Old 01-03-2015, 11:29 PM   #15
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,842

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


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
could SystemTap be used by malicious person to steal ssh password easily ? wzis Linux - Security 4 05-03-2014 07:43 PM
how to specify password for sudo command when running bg process? sneakyimp Linux - Newbie 9 06-30-2010 02:14 PM
Freeing I/O resource held by zombie process kronesr Linux - Software 2 02-22-2010 11:29 AM
child process usses same amount of ram as parent process socialjazz Programming 7 10-19-2006 05:48 PM
Forward X / Steal a process sval Linux - General 0 12-30-2004 10:32 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 04:44 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration