A Rough Year for SSH

In 2001, ssh was found to have several security flaws and has improved thanks to its trials.

Just as 2000 was a rough year for firewalls, with holes blown in both commercial and open-source products, 2001 was a most uncomfortable year for the secure shell, or ssh. Several groups focused their attentions on this cornerstone of the net, and several problems emerged. ssh has emerged from this scrutiny a stronger product.

Not all of these issues affect all ssh users, so it's important to understand the vulnerabilities, their impact, and how to mitigate these risks. In this piece, several of the vulnerabililities found in 2001 are discussed, and some general recommendations for the ssh user are offered.

Briefly, two major vendors of ssh products have emerged, SSH Communications, who originally developed the software, and OpenSSH, who produce an open-source derivative. When referring to the ssh client from SSH Communications, the term Ssh will be used. When referred to the OpenSSH client, the term OpenSSH will be used. This is important as they sometimes do not share security vulnerabilities. SSH1 refers to the version 1 protocol for ssh, and SSH2 refers to the second version of the protocol.

Starting 2001 with a Bang

The year 2001 saw folks geared up to abuse ssh through monkey-in -the-middle attacks, facilitated by the release of dsniff-2.3 in late 2000. dsniff, from the well known and respected security professional Dug Song, is a super sniffer and network penetration tool. Among the tools it includes is a tool to perform "man-in-the-middle" attacks on SSH1, allowing an attacker to eavesdrop on an SSH1 connection. The attack relies on a combination of factors, including a DNS spoof and the server's key not being in your cache, or the user accepting the new key as the valid server's key. In doing this, the attacker fools the ssh client into connecting to them, rather than the intended server, while the eavesdropper completes the connection. By negotiating the session key for encryption, the attacker can observe the full ssh session.

The attack is nothing new, but the release of dsniff-2.3 made this much simpler. Since then, new releases of Ssh have integrated PKI, or Public Key Infrastructure, support, allowing for the verification of server keys through a chain of trust. Use of the tool only increased in 2001, but also had the effect of helping people learn public key authentication more readily.

Revealing Just a Bit of a Secret

Dug Song also worked with another hacker on yet another attack on SSH1, which reveals the password length during authentication. Working with Solar Designer, who is known for his Linux Auditing Project work, the two developed a tool to ascertain the exact size of the password, which can facilitate the cracking of the password by a factor of 50. While it doesn't reveal anything else about the password, including the composition, together with additional information this can be useful for an attacker. When this is combined with a subtle bug I found in early 2001, which revolves around a failure to log repeatedly unsuccessful login attempts in Ssh but not OpenSSH, attacks on networks can be facilitated.

This affects mainly SSH1, as the password authentication mechanism in SSH2 doesn't reveal as much information. OpenSSH has some implementation fixes in place, but Ssh has not committed the fixes, citing the deprecation of SSH1 and the related code.

Munching on Traffic Analysis

At the USENIX Security Conference in 2001, researchers from the University of California, Berkeley developed an attack on the traffic that ssh uses during communications. The attack has generated a significant amount of press due to its beauty and creativeness, however it remains a rather academic attack. A tool, named Herbivoir, was also released to demonstrate the technique, with the name being an obvious pun on Carnivore, the FBI e-mail sniffer.

Briefly, by observing the traffic (the concept of traffic analysis) and its patterns, the commands being issued by the client can be guessed. Furthermore, by observing the responses, a command like "su" can be picked out. And because the timing between keystrokes can be measured, the length and basic composition of the password can be ascertained. The weakness comes from the way ssh packets are handled, which is with a high value on interactiveness, using a minimal delay between input and sending the packet. As such, a single ssh packet often includes only one keystroke.

The attack is, as noted above, very academic. Simply put, the analysis of the interkeystroke timings requires a large training set, as every individual types with different patterns. Secondly it requires a constant delay in observations so as not to skew the measured timings. As such, it seems out of reach of most attackers, and only reveals a portion of the data needed to mount a successful attack.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Don't ignore lsh !!

Anonymous's picture

Why do you ignore lsh, which is GNU software, covered

by the regular GPL license? It does only support SSH2 since there are security problems inherent in the SSH1 protocol. If you don't have a problem with that, try it out! It is somewhat different to use than Ssh or OpenSSH, but well worth it.

The latest version can be donwloaded from http://www.lysator.liu.se/~nisse/archive/

and is today 1.3.6

How many security holes has lsh had this year? None. (AFAIK, I'm just a user)

Re: Don't ignore lsh !!

Anonymous's picture

Why? Licence bigotry does nothing to advance either security or Free software. The whole BSD vs GPL holy war results in far too much brainpower being wasted on unnecessary duplication of effort. The fact that no vulnerabilities have been found in Ish does not demonstrate that it is bug-free; it means that it's an unknown quantity. The fact that OpenSSH has had holes discovered (and plugged!) helps demonstrate it's maturity and gives concrete proof of it's ability to survive real-world attack scenerios. It would be foolish to rely on unknown and unproven software in a mission-critical role.

Re: Don't ignore lsh !!

Anonymous's picture

A note from the lsh home page:

You may not want to depend on lsh just yet...

Re: A Rough Year for SSH

Anonymous's picture

Informative article.

Re: A Rough Year for SSH

Anonymous's picture

I have a GPL'd tool that installs ssh keys at http://www.stearns.org/ssh-keyinstall/ Additionally, I have some tutorials at