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

issue can be avoided

[neodymium]

It is a well known vulnerability that passwords can be reconstructed out of key timings - but this issue can be avoided easily, i.e. with terminal applications sending the whole password at once.

Re:issue can be avoided

[Anonymous Coward]

They are talking about passwords entered after you log in. To things like sudo, or SQL front ends, or other crap like that.

I do not believe you are correct, from their document [berkeley.edu] it appears they are focussing on the initial login.

Believe it. In SSH2 the initial login password is buffered by the client and then sent in 8 byte chuncks, so you cannot get any keypress-timing information from the initial password.

Re:Is it really easier...?

[Anonymous Coward]

Try using ngrep and telnet.

its not that "TCP/IP" sends one character in each packet. its like this:

SSH and telnet are supposed to simulate exactly what happens if you press a certain key on a certain box. Of course they are not going to wait for an enter key. these clients are not "smart". they dont even know if you are using pine or entering a passwd. if they had to wait for an enter key, they would have to wait for an enter key when you press "I" in pine. this ofcourse, would be a big problem.

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!

If you care, use key-based authentication!

[DougM]

If you are this paranoid then you would already be using public key authentication.

I knew one manager who wanted to disable SSH and go back to telnet/ftp because of the SSH1 deattack vulnerability! Let us keep these things in perspective.

Quick solution

[CyberBry]

Am I the only one who sees a quick solution to this problem, that doesn't even require a patch?

When you're typing in your password, don't type it in fluidly. Just wait a second here or there between random letters when you enter it. It'll confuse the heck out of anyone trying to sniff it from you ;)

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.

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....

Re:OpenSSh - no problem

[jimmcq]

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.

AFAIK, *every* version of SSH has done that. The logon password isn't the issue... the issue has to do with passwords that are typed *during* the session... such as when you 'su'.