Slashdot Mirror

← Back to Stories (view on slashdot.org)

SSH Taking Stand On Vulnerability

Posted by Hemos on from the spinning-the-press dept.

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

4 of 90 comments (clear)

  1. So what.. by eye.likeJava() · · Score: 4, Insightful

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

    --
    ... although I also like C#..
  2. Re:Is it really easier...? by q[alex] · · Score: 5, Informative

    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

    --
    I am the king... of No Pants! www.penny-arcade.com
  3. New Technique realeased by gad_zuki! · · Score: 4, Funny

    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

  4. Simple to avoid, really by Dr.+Blue · · Score: 5, Informative
    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....