gpg over ssh... (security problem)

[Erpo]

On Sun, 2005-03-20 at 10:09 +0100, Gerhard Siegesmund wrote:
> Say, I have a encrypted file somewhere on a server on the net.
> Naturally I don't have my private key on that "unsave" server. I want
> to use the output of the encrypted file in a pipe to do something with
> it.
> 
> I don't like the idea to send the encrypted file back to my home-server
> to decrypt it there and then send back the decrypted file to the
> work-server. Also this would work, I would have to remember to remove
> the decrypted file after the action.
> 
> My idea was to do something like the following:
> 
> cat encrypted_file.gpg | ssh me at my.home.server gpg --decrypt | do_something.sh
>
>[...]
>
> So. Does this way sound correctly in your ears? How about security
> (apart from the point, that my homeserver is available from the net,
> which I know lowers my security a lot. I hope, my password is good
> enough.)? Is this at all possible?

There is a security problem here. The point of not keeping your secret
key on the remote server is that someone could find a way to access
files that are only accessible to your user account on the remote
server. But if someone could access files on the remote server in this
manner (say, by rooting it or cracking your password), that person could
also modify files in your account (say, .bash_profile) so that when you
try to execute a command like:

cat encrypted_file.gpg | ssh me at my.home.server gpg --decrypt |
do_something.sh

the remote server instead executes a program, designed by the attacker,
that records your home machine's password as well as your passphrase.
The effect is the same: the attacker would be able to use your private
key.

Nor would it be secure to reverse roles in this situation. Suppose you
wrote a script on your home machine that connects to the remote server,
pulls down the file to be decrypted, decrypts it, sends it back to the
remote server, executes a command on the remote server, and deletes the
decrypted file on the remote server. Then an attacker who has
compromised the remote server could, upon detecting your running this
type of script (by any number of means), could replace the file you
intend to download with any encrypted message to you and could replace
the server-side command you intend to run on the decrypted data with a
command that makes a copy of it somewhere out of the way. The attacker
would not be able to access your private key, but she would be able to
decrypt any chosen piece of your encrypted data.

The only thing you know for certain is that a server that has been
compromised is a server that does whatever an attacker wants it to.
Using a scheme like the proposed one is only marginally better than not
encrypting your data at all. That said, these schemes (in the order
presented) require respectively increasing levels of technical
sophistication on the part of the attacker.


Eric