---------- Forwarded message ---------- Date: Wed, 17 Jan 96 16:46:28 EST From: Barry Jaspan To: ssh@cs.hut.fi, ssh-bugs@cs.hut.fi Subject: Security bug in ssh.c (1.2.0) Responding to a challange from Wayne Schroeder , I just found a bug in the RSA Rhosts code in ssh.c that allows any user that can run the ssh client to obtain the private key of the host it is running on. Once an attacker has that key, of course, he can break the security of any host that trusts the attacked host. The bug is that ssh.c does not erase the host's private key from memory before setuid()ing back to the user. Therefore, it is possible for the user to access the memory containing the private key before it is erased. The attack is simple. The user runs ssh, watches (via stat()) for the access time on /etc/ssh_host_key to change, and as soon as it does sends a SIGSEGV to the process. It is then a simple matter of running a debugger on the core image to extract the private key. I performed the attack with a 15 line perl script that I wrote in about 20 minutes. A user cannot send a signal to a root process. Therefore, the bug can be eliminated by erasing the key from memory before relinquishing root privileges. Of course, this means a lot more code has to be run as root, and all that code will have to be verified to be setuid-safe. Lessons to be learned: o Host-based trust is a BAD IDEA. Securing it with RSA does not change the fact that compromise of a single host compromises all the hosts that trust it. No one should use the RSA Rhosts mode of SSH if they care about security. SSH should not even include that functionality. o SSH is too new to be trusted for real security applications. It needs to be tested and evaluated by security experts over a long period of time. I found and exploited a critical bug in only about 20 minutes. How many others remain to be discovered? Barry