Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: How necessary is SSH_AUTH_SOCK?

Subject: Re: How necessary is SSH_AUTH_SOCK?
Date: Mon, 2 Oct 2006 13:03:00 -0400
On Sun, Oct 01, 2006 at 09:38:56AM -0500, Steven Elliott wrote:
On Fri, 2006-09-29 at 11:11 +0200, Markus Friedl wrote:
On Thu, Sep 28, 2006 at 12:17:17AM -0500, Steven Elliott wrote:
So my question is - Why doesn't ssh-agent default the location of the
socket file to some well known fixed secure location such
$HOME/.ssh/agent? 

$HOME might be on a nfs server, so -a $HOME/.ssh/agent
is not the default.

How is having the socket file on an NFS server a problem?  I know that
other applications do it, such as evolution / spamd:
    /home/sle/.evolution/cache/tmp/spamd-socket-path-bz4CuE

On most platforms, this is a gigantic mistake, particularly if the
data is or could be sensitive (as is the case with authentication
credentials provided by ssh-agent).  There are at least two problems
that I can think of off the top of my head:

1. In general, NFS does not encrypt the data that goes over the wire.
   Thus authentication data supplied via the socket can be sniffed by
   virtually anyone with physical access to the network, unless the
   network admins go through rather a lot of pain to make it
   difficult.  Most simply do not.  [Yes, switched networks CAN be
   sniffed too.  It's harder, but very possible, and really not that
   much harder if you know/have access to the right tools to do it.]

2. In a lot of computing environments, people are allowed to have the
   root password to their individual workstation.  This is a mess in
   an NFS environment, as it means anyone can read any files which are
   exported to their machine, with the sole exception of any exported
   files owned by root.  So again, this would grant anyone and
   everyone the ability to get your authentication credentials from
   the socket.

If you're not using Kerberized NFS (and as yet odds are you aren't),
NFS should generally be assumed to be insecure for sensitive data.
With some pain it can be more secure (i.e. access controls on all your
switches, and making sure no one has the root password to any machine
which gets NFS mounts, per-user exports to user-specific machines,
etc.), but I've yet to see a single environment that does all of
what's needed to make it reasonably secure, simply because it's a
monumental pain to set it up and maintain it.

Also, I believe there are some nework filesystems which don't support
named sockets (AFS I believe, though I may be mistaken...  CIFS?  I
don't know but I'd guess not)...  If the environment uses such
filesystems for home directories, it simply won't work at all.  The
best place to put such files is generally in a directory in /tmp which
is owned by the user and set to 700 permissions, but the application
must still ensure that the directory tree has appropriate permissions
to prevent the removal or renaming of files leading up to that point
in the file system heirarchy, or else a malicious user could
potentially still replace the file with one they have access to.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

Attachment: pgplxNJvpgztz.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>