vulnerability with ssh-agent

[Keld Jørn Simonsen]

On Wed, Jul 14, 2004 at 09:31:11PM +0200, Nils Larsch wrote:
> 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

Yes, I already found out, but it was a bit embarrassing to correct my
mistake on the list. As you may have noticed, I am not a regular openssh
hacker. My idea was to then use something like gdb to access the
/proc/pid/mem to see if the keys were encrypted or not.

I have taken the sources and done a little hacking, and I noticed a
remark that the encryption of sensitive information in ssh-agent was a
"TODO". So somebody else than me, and with some status in the project,
enough to make comment on what to do, has also considered it a good
idea, to encrypt keys and other stuff.

I understand that my level of competence here is way lower than that of
a openssh hacker, but anyway, where there is a will, there is a way. 
I am appauled by the ease it is to use the ssh-agent for an intruder.
So I have begun to do some hacking, and noticed that tcsh actually
closes all its inherited file descriptors, so that fork() inheritance of fd's
don't work. However, in bash the fd's survive. I have also found out that
there is a separate namespace for sockets - I think the name is
socket:[number] but I am not sure of this. This is the name that is
recorded in /proc/pid/fd and it is probably accessible for a program
with root permissions without inheriting the fd. Furthermore I noticed that
there is something called anonymeous sockets, and that is probably the
way forward. I am not sure tho, that you can listen to it, so that you
may have more sockets open, from different ssh clients, or if it is
necessary - there may be one fd that several processes can use
concurrently.  But an anonymeous socket would probably not be accessible
to processes that don't inherit it, or get it as a gift, so that would
be safe. 

I have also considered other ways of doing inter-process communication
in a safe way, but sockets are probably the way to go.

I also need to consider whether the ssh -c option is enough for me and
my small advisory, and if it works as I would like it to do.

Anyway, I don't expect that people from the list comment on this. I understand that I
need to show something more concrete to the list, and I think I will
find the time to dwelve into it, but if you feel like it, you are welcome
to comment and save me some hours on digging out documentation and
hacking. 

Best regards
Keld