Security [LWN.net]

OpenSSH and keystroke timings

By Jake Edge
September 17, 2008

Theoretical security weaknesses have a tendency to move from the realm of theory to that of practice over time. Sometimes it is the result of more compute power being applied or better algorithms being developed, but a weakness is certainly not going to get stronger. So when Kevin Neff started discussing fixing a weakness in OpenSSH on the openbsd-misc mailing list, the folks writing it off as "theoretical" may have been jumping the gun.

When it is in interactive mode—a user typing into a terminal session for example—ssh sends each key pressed by the user in a separate packet. By observing the timing between packets, an observer may be able to determine something about what was typed just by using traffic analysis, without attempting to break the encryption. Researchers found that the inter-packet timing correlated well with the inter-keystroke timing, so that using statistical techniques they were able to reduce the search space for cracking a password by a factor of 50.

This weakness was outlined in a 2001 paper entitled Timing analysis of keystrokes and timing attacks on SSH" [PDF] which looked specifically at the timing-based attack:

In this paper we study users' keyboard dynamics and show that the timing information of keystrokes does leak information about the key sequences typed. Through more detailed analysis we show that the timing information leaks about 1 bit of information about the content per keystroke pair. Because the entropy of passwords is only 4-8 bits per character, this 1 bit per keystroke pair information can reveal significant information about the content typed.

The paper looked at the now-deprecated SSH1 protocol, which led some to conclude that it substantially invalidated the weakness. Damien Miller pointed out that it was likely to still be valid:

There is no reason to believe that keystroke timing attacks will be impossible against protocol 2 where they work against protocol 1. They might just be a little more tricky.

Pointing at the paper and discounting it because it is ssh1 only is sticking your head in the sand. It is usually easier to research attacks on simpler protocols and work up to more complicated ones later.

There is a fair amount of information that can be gleaned just by looking at the traffic generated over an encrypted session, especially if the attacker can gather a sizable amount of it. There are fairly clear patterns in interactive sessions that can be extracted and used alongside the inter-keystroke timing information to potentially garner lots of useful information. Darrin Chandler describes it this way:

The reason why I think it's a weakness is that you can gather statistics on typing and use those to infer things. I.e., you can extract meaningful information from the encrypted session. If you're snooping on ssh and see a short burst of typing followed by another ssh session from the remote machine you can guess they typed 'ssh host.example.com' by the length of typing and the host connected to. Nice crib. Oh, after than connect was there another short burst? Probably the password. How many keystrokes can probably be inferred. Perhaps stats on interkey timing can be used to make some intelligent guesses, such as the 4th char is NOT punctuation because is followed char 3 too closely. Or whatever.

Overall, the reception to making OpenSSH less susceptible to this kind of analysis was positive. It is clearly a difficult attack to mount, logistically if nothing else, but it is not impossible either. Better timing information or analysis techniques might make it easier over time as well and that is enough of a reason to look at ways to fix it.

Comments (21 posted)

Brief items

NoScript 1.8.1 and LWN logins

We have received several reports of readers being unable to log in to LWN.net this morning. It appears to be related to upgrading the NoScript Firefox plugin to version 1.8.1. A new feature, called "Automatic Secure Cookie Management", appears to interact badly with LWN's login code. Some workarounds are described in the FAQ. We apologize for any inconvenience.

Update: Peter Palfrader reports that whitelisting lwn.net for "unsafe" https cookies in NoScript Options -> Advanced - HTTPS -> Cookies -> Enable Automatic Secure Cookies Management fixes the issue.

Comments (24 posted)

New vulnerabilities

apache2: cross-site scripting

Package(s):

apache2

CVE #(s):

CVE-2008-2939

Created:

September 15, 2008

Updated:

December 5, 2008

Description:

From the Mandriva advisory:

A cross-site scripting vulnerability was found in the mod_proxy_ftp module in Apache that allowed remote attackers to inject arbitrary web script or HTML via wildcards in a pathname in an FTP URI (CVE-2008-2939).

Alerts:

Red Hat	RHSA-2008:0966-02	2008-12-04
rPath	rPSA-2008-0327-1	2008-11-22
rPath	rPSA-2008-0328-1	2008-11-22
CentOS	CESA-2008:0967	2008-11-11
Red Hat	RHSA-2008:0967-01	2008-11-11
SuSE	SUSE-SR:2008:024	2008-11-07
Mandriva	MDVSA-2008:195	2007-09-13
Mandriva	MDVSA-2008:194	2008-09-13

Security

OpenSSH and keystroke timings

NoScript 1.8.1 and LWN logins

apache2: cross-site scripting

ipa: remote password exposure

kernel: integer overflow

kernel: multiple vulnerabilities

kolab-server: password disclosure

libxml2: denial of service

libxml2: buffer overflow

openssh: denial of service

pam_mount: arbitrary mounting of filesystems

postfix: denial of service

R-base: arbitrary file overwrite

redhat-ds-base: multiple vulnerabilities

rsh: directory traversal

ssmtp: memory contents disclosure

wireshark: multiple vulnerabilties

wordnet: buffer overflows

wordpress: SQL column truncation