SSH Taking Stand On Vulnerability

jeffy124 writes "SSH Communications is recognizing the vulnerability claim made by UC Berkeley researchers earlier this week. They say it is not a practical threat to the ssh protocol, people can still remain confident in keeping communications over ssh private. While this is true IMO, they are open to and will be researching techniques that would make the standard stronger, along with hopes of lessening this vulnerability."

Comments

So what..

[eye.likeJava()]

It is a sort of exploit, but it goes close along the lines of "well what happens if the hacker calls halt on the machine and dumps memory" like any program can do anything much about that..

If you have people capable of reconstructing passwords from key timings then you have got yourself a problem.

The only solution is to inject fake data..

Re:Is it really easier...?

[q[alex]]

telnet from one machine to another, and snoop/tcpdump that traffic. what you'll see is something like this: (sanitized for obvious reasons)

host.from -> host.to TELNET C port=35957
host.to -> host.from TELNET R port=35957 login:
host.from -> host.to TELNET C port=35957 a
host.to -> host.from TELNET R port=35957 a
host.from -> host.to TELNET C port=35957 l
host.to -> host.from TELNET R port=35957 l
host.from -> host.to TELNET C port=35957 e
host.to -> host.from TELNET R port=35957 e
host.from -> host.to TELNET C port=35957 x
host.to -> host.from TELNET R port=35957 x
host.from -> host.to TELNET C port=35957
host.to -> host.from TELNET R port=35957 Password:
host.from -> host.to TELNET C port=35957 4
host.to -> host.from TELNET R port=35957
host.from -> host.to TELNET C port=35957 2
host.to -> host.from TELNET R port=35957

That's telnet, clear text. Note how each user input has it's own packet. If you use -v, you can get very precise timing on these packets.

Now with SSH, obviously, the user data is going to be encrypted. But the data is still going to be sent one keystroke at a time.

ssh, telnet, etc were all designed to be terminal emulation compatible (or something like that), which esentially means that they need to behave just like those old paper-based TTYs. think about it for a few minutes, why do you think linux assigns you a TTY when you telnet to it? because parts of the kernel think you're actually sitting at one of those TTYs. and those TTYs sent and returned each keystroke, because early usability studies noted that most users equate response time with speed.

hth,
alex

Yes, SSH.com's product works fine with OpenSSH

[Raetsel]

I know, I use the SSH.com client to talk to the OpenSSH (on OpenBSD) server. However, I don't use the key-exchange methods, so I can't comment on that facet.

The SFTP function is a really nice feature, too. All I had to do was enable the server in the OpenSSH /etc/sshd_config file, and it just worked. Beautiful.

Finally, they offer a free "educational, charity, and personal recreational/hobby use" license -- just the thing for using my Windows desktop to talk to my home firewall.

I've never had a hiccup... no complaints at all! I think that's as much a credit to OpenSSH as it is to SSH.com -- they have a standard, and they've stuck to it!

OpenSSh - no problem

[cehf2]

It appears, using openssh 2.9p2 (that currently in debian/unstable) that it sends the entire password in one TCP packet, so no problem there then.

Re:OpenSSh - no problem

[jareds]

It appears, using openssh 2.9p2 (that currently in debian/unstable) that it sends the entire password in one TCP packet, so no problem there then.

The issue is not, and never was, with the initial password that ssh sends for authentication, but rather with using, for example, su or ssh within an ssh session.

Another solution

[Falsch Freiheit]

Use the key (RSA or DSA) authentication as your normal method of authentication. Heck, if you set up the ssh agent it's even more convenient than password based authentication.

And I did a quick check (tcpdump in one window, ssh in in another window) and there's no packet sent for each stroke of my password, one packet is sent when I hit <enter> at the end of my password. I suppose length could probably still be figured out from those packets, though. I'm running OpenSSH 2.5.2p2 (the version that came from RedHat with RH 7.1)

New Technique realeased

[gad_zuki!]

researching techniques that would make the standard stronger, along with hopes of lessening this vulnerability."

Whe you see that lock thingy on your browser just switch your hands on the keyboard. That's right, put your right hand on the left side of the keyboard and vice versa. We were going to write a technical paper on this put I just drew a picture on a napkin this morning.

Sinceretly,

SSH Communications

Simple to avoid, really

[Dr. Blue]

I was at the Usenix Security Symposium where this result was presented, and I've got to say that while it is marginally cool it is not a real, practical security threat. The only real information that's definitely given away is the length of the password. They build a hidden Markov model that can rank possible passwords by probability -- that allows you to find passwords faster in a brute force search, but there are so many uncertainties that it would still never work in the real world, with real-length passwords (their tests used a reduced alphabet and short passwords... I think they only used a set of 15 possible characters for their passwords).

The timings that were used as a basic model were also taken from experienced touch-typists. The woman who presented the results said that there is a very simple countermeasure (she was joking, I think, but it's a very valid point): if you normally touch-type, just use a single finger to hunt-and-peck your passwords -- then the timings aren't what they "should" have been, and in fact their attack could actually make things worse by sending you down the wrong path to the password.

Anyway, I'm surprised this has gotten so much attention -- it is cool, but it really isn't practical in the least....

Mostly Nonsense

[fanatic]

I tested in openSSH2.5.1p2 - the login password is sent in one packet, so the inter-key timing attack is crap for this.

The interkey timing applies ONLY AFTER the initial login. The cracker would have to have to somehow know you were exceuting something that involved entering a password, then capture the packets with your keystrokes.

This is getting way more play than it deserves, IMO.