Hi I have written a small introduction to newbies in Danish on ssh and friends. Now some people are questioning my advice and I think they have a point. I am advocating people to use DSA-keys and a config file with this: Protocol 2 ForwardAgent yes ForwardX11 yes Compression yes CompressionLevel 9 and running ssh-agent and ssh-add, and then loggin in without giving keys. One commenter said that this has big holes. An intruder with root privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found in /tmp, and he could also find the keys in the /proc area for the ssh-agent. Is that true? Are the keys visible under Linux in the /proc memory mapping for ssh-agent? Could there be done something to better these vulnerabilities? I was thinking along the lines of deleting the socket in temp, if an option "delete_ssk_auth_socket" was given in config, and then only processes that inherited the socket via fork() would have access to the socket, via an open file descriptor. An intruder would then need to program opening of an inode that was deleted, which is much harder than just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. This would work fine in the standard setup, where ssh-agent is launched as part of the initiation of X. If forwardagent is on would there be keys stored in the memory on the machine logged in to (thus findable in /proc), or will ssh-agent there always refer back to the machine logged in from? Would there be a way for ssh-agent to have the keys stored in memory, so that is not easily found in /proc? Best regards Keld Simonsen
If its in memory, you should assume that root can see it. Mike On Tue, 13 Jul 2004 21:13:47 +0200, Keld J?rn Simonsen <keld at dkuug.dk> wrote:> Hi > > I have written a small introduction to newbies in Danish on ssh and > friends. Now some people are questioning my advice and I think they have > a point. > > I am advocating people to use DSA-keys and a config file with this: > > Protocol 2 > ForwardAgent yes > ForwardX11 yes > Compression yes > CompressionLevel 9 > > and running ssh-agent and ssh-add, and then loggin in without giving > keys. > > One commenter said that this has big holes. An intruder with root > privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found in > /tmp, and he could also find the keys in the /proc area for the > ssh-agent. > > Is that true? > Are the keys visible under Linux in the /proc memory mapping for ssh-agent? > > Could there be done something to better these vulnerabilities? > > I was thinking along the lines of deleting the socket in temp, if an > option "delete_ssk_auth_socket" was given in config, and then only > processes that inherited the socket via fork() would have access to the > socket, via an open file descriptor. An intruder would then need to > program opening of an inode that was deleted, which is much harder than > just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. > This would work fine in the standard setup, where ssh-agent is launched > as part of the initiation of X. > > If forwardagent is on would there be keys stored in the memory on the > machine logged in to (thus findable in /proc), or will ssh-agent there always > refer back to the machine logged in from? > > Would there be a way for ssh-agent to have the keys stored in memory, so > that is not easily found in /proc? > > Best regards > Keld Simonsen > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >
> One commenter said that this has big holes. An intruder with root > privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found in > /tmp, and he could also find the keys in the /proc area for the > ssh-agent.if you have "an intruder with root privileges", you have bigger problems> Could there be done something to better these vulnerabilities?don't forward your agent to untrusted machines
Keld J?rn Simonsen wrote:> I was thinking along the lines of deleting the socket in temp, if an > option "delete_ssk_auth_socket" was given in config, and then only > processes that inherited the socket via fork() would have access to the > socket, via an open file descriptor. An intruder would then need to > program opening of an inode that was deleted, which is much harder than > just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. > This would work fine in the standard setup, where ssh-agent is launched > as part of the initiation of X.Even if you could make this work, the socket would still be accessible to root on Linux under /proc/pid/fd. -- Jefferson Ogata <Jefferson.Ogata at noaa.gov> NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
Michael Stevens wrote:> If its in memory, you should assume that root can see it.yes, that is of cause true, but I am not sure that the dsa key is in the memory of the ssh-agent, and I am not sure that it will be easily visible. I had a try if I could find my dsa key in the /proc/pid/exe file of the ssh-agent with strings, but I could not find it. Does anybody know if ssh-agent has the keys stored in memory, and how? best regards keld
joshua stein wrote:> I wrote: > > One commenter said that this has big holes. An intruder with root > > privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found > > in /tmp, and he could also find the keys in the /proc area for the > > ssh-agent. > > if you have "an intruder with root privileges", you have bigger > problemsActually not necessarily so. The intruder with root privileges may have broken in on my home system, but that is something I can deal with. The intruder can via these techniques get access to some servers where I have stored my dsa keys, and that would be a much bigger problem. Best regards Keld
Jefferson Ogata wrote:> Keld J?rn Simonsen wrote: > > I was thinking along the lines of deleting the socket in temp, if an > > option "delete_ssk_auth_socket" was given in config, and then only > > processes that inherited the socket via fork() would have access to > > the socket, via an open file descriptor. An intruder would then need to > > program opening of an inode that was deleted, which is much harder > > than just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. > > This would work fine in the standard setup, where ssh-agent is > > launched as part of the initiation of X. > > Even if you could make this work, the socket would still be accessible > to root on Linux under /proc/pid/fd.Hmm, I had a look, and sure, there were file descriptors in /proc/pid/fd . But they did not have the same inode description as the ones in /tmp/ssh-*/ Can these fd's be used in the SSH_AUTH_SOCKET ? and what are they good for anyway? Who uses them, and could they be removed (out of the kernel) as a kind of security option? Or could there be invented other ways so that the ssh-agent could not be misused by an intruder with root privileges? Best regards keld
Keld J?rn Simonsen wrote:> Michael Stevens wrote: > > >>If its in memory, you should assume that root can see it. > > > yes, that is of cause true, but I am not sure that the dsa key > is in the memory of the ssh-agent, and I am not sure that it will be > easily visible. I had a try if I could find my dsa key in the /proc/pid/exe > file of the ssh-agent with strings, but I could not find it./proc/$PID/exe is a link to the executable file and _not_ the process memory, for that you have /proc/$PID/mem (or /proc/kcore) see the proc manpage Nils
On Wed, Jul 14, 2004 at 09:09:54PM +0200, Keld J?rn Simonsen wrote:> Does anybody know if ssh-agent has the keys stored in memory, and how?of course they are in the memory (unless you have a smartcard). where else?
On Wed, Jul 14, 2004 at 10:07:16PM +0200, Markus Friedl wrote:> On Wed, Jul 14, 2004 at 09:09:54PM +0200, Keld J?rn Simonsen wrote: > > Does anybody know if ssh-agent has the keys stored in memory, and how? > > of course they are in the memory (unless you > have a smartcard). where else?are they also stored in memory, if you use forwardagent (on the intermediate machine)? And how are they stored, have something been done to make them harder to retrieve from a dump? best regards keld
Keld J?rn Simonsen wrote:> I have written a small introduction to newbies in Danish on ssh and > friends. Now some people are questioning my advice and I think they have > a point. > > I am advocating people to use DSA-keys and a config file with this:As I understand it RSA keys are both faster and more secure for the same number of key bits. Which is why DSA keys must be much bigger than RSA keys to provide a similar level of strength. Both of which makes DSA keys slower. As I understand it the only reason for DSA keys was to avoid the RSA patent now expired by four years. But is is now expired and so longer poses a restriction. I would use RSA keys. They are strong, fast and compact. Bob