ssh exploit – how to avoid it

ssh exploit – how to avoid it

Over IRC, I’ve learned about an SSH exploit. And I’ve also learned how to avoid the exploit. I’m not
claiming to be an expert in this area. I do claim to be relaying information which might help you. Those
amongst you that know more about this area than I will hopefully add their comments to this article.

What’s the exploit?

This vulnerability is described in
CERT Vulnerability note VU#945216. Their description
of the problem is:


There is a remote integer overflow vulnerability in several implementations of the SSH1 protocol that allows an attacker to
execute arbitrary code with the privileges of the SSH daemon, typically root.


The details of the analysis are at
http://staff.washington.edu/dittrich/misc/ssh-analysis.txt.

The FreeBSD Security advisory is at
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-01:24.ssh.asc.

So what isn’t vulnerable?

My understanding is that FreeBSD 4.3 onwards is not vulnerable to the SSH1 exploit. Even if you have an older FreeBSD,
you can avoid the exploit by using SSH2 instead of SSH1. How do you do that? Read on…

Of course you could merely upgrade your FreeBSD to the latest version. Or you could
install the OpenSSH port.

Using ssh2

Given that SSH1 is vulnerable, how can you reduce your exposure? First, you need to realise that it
is still very difficult to exploit the SSH1 bug. Second, some clients are not SSH2 capable. That
said, I think there are a few simple steps you can undertake in order to reduce your exposure.

The easiest step is to ensure that both your clients and your servers use SSH2 instead of SSH1,
if it’s available. How to do that is outlined below. A more dramatic step would be to require
SSH2. But that’s not for everyone.

Change your servers

You can specify the protocols used by your sshd via /etc/ssh/sshd_config.
Look for the entry which looks like this:


Protocol 1,2


That specifies that both protocols 1 and 2 should be accepted. It does not determine which
protocol will be tried first. That decision resides with the client.
The following is from man sshd:


Protocol
Specifies the protocol versions sshd should support. The possible
values are `1'' and `2''. Multiple versions must be comma-separated.
The default is `1''.


If you wish to use only SSH2, that is an option. But consider it carefully. The SSH1 exploit is difficult to
achieve. Some clients are not SSH2 compatible. If you can ensure that all your clients will be SSH2-compatible,
then, and only then, is SSH2 only an option for you. If so, adjust your configuration file to be this:


Protocol 2


WARNING: Use the above with caution considering who your clients will be.

Change your clients

The change to your clients are quite similar to your sever changes. The file
to modify is ~/.ssh/config (which might not exist
on your system; you may need to create it). I added the following line:


Protocol 2,1


The following is from man ssh:


Protocol
Specifies the protocol versions ssh should support in order of
preference. The possible values are ''1'' and ''2''. Multiple
versions must be comma-separated. The default is ''1,2''. This
means that ssh tries version 1 and falls back to version 2 if
version 1 is not available.


Note that order is significant. In the example above, Protocol 2 will be tried and then protocol 1.

You can also specify protocol 2 using the command line:

ssh -2 example.org

or

ssh -o "Protocol 2,1" example.org

Create and use SSH2/DSA keys

The following two resources are compulsory reading if you are using SSH. It describes how to properly
manage OpenSSH keys. It will also show you how to use the more advanced features of OpenSSH.

• http://www-106.ibm.com/developerworks/library/l-keyc.html
• http://www-106.ibm.com/developerworks/library/l-keyc2/

You can create SSH/DSA keys using ssh-keygen -d. Definitely specify
a passphrase. Reading the above URLs will show you how to use ssh-agent to reduce the number of
times you need to enter the passphrase. It’s very useful.

Your public DSA key (~/.ssh/id_dsa.pub) needs to be added to
~/.ssh/authorized_keys2 on the remote box (i.e. the sshd server).
Read the above URLs for complete information.