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

90 comments

  1. Do they do the commercial one? by codeforprofit2 · · Score: 2, Insightful

    How is it with openssh?

  2. 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#..
  3. shh! by qwerty123 · · Score: 0, Offtopic

    The best way to keep private is wispering... shh!

  4. issue can be avoided by neodymium · · Score: 2, Informative

    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.

    1. Re:issue can be avoided by Tet · · Score: 2
      this issue can be avoided easily, i.e. with terminal applications sending the whole password at once.


      Or with SSH by just not sending the password across the network at all. Using RSA euthentication completely nullifies this potential vulnerability.

      --
      "The invisible and the non-existent look very much alike." -- Delos B. McKown
    2. Re:issue can be avoided by ZxCv · · Score: 1

      Oddly enough, I believe the Windows SSH client we use at work uses this approach (SecureCRT 3). I don't see why every implementation doesn't use this method, as it is obviously trivial to code and provides that extra little layer of security (ie, enough to thwart this new "attack").

      --

      Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
    3. Re:issue can be avoided by garcia · · Score: 2

      most GUI implementations do. SecureCRT, MacSSH, etc. Most of the Linux lovers that I know (and myself) use the commandline version which has you enter your password in the standard way.

    4. Re:issue can be avoided by Anonymous Coward · · Score: 0

      Yes, when you first login with SSH all clients (that I know of) send the password as in one packet. I *think* the issue is when you do other stuff once you have your SSH session going. For example if you login as yourself then "su" to root SSH can't know you are enterig a password.

    5. Re:issue can be avoided by gazbo · · Score: 1

      The researchers make two claims about how password transmission can weaken security:

      In the first they claim that by analysing key timings they can attack passwords up to 50 times faster. We'll assume that they are not exaggerating and that this is based on real life tests.

      The second claim they make is that it allows the length of the password to be ascertained immediately, giving a significant advantage. However, simple maths shows that a password based on a set of n characters has ~(n-1) more permutations than the sum of all shorter passwords. Hence, in a strong password we see that attacking the shorter passwords is virtually noise compared with the time taken to attack the correct length password.

      So really the result is an approximate 50 times speedup in brute force attacks, as suggested by the first claim. Once again, assuming we are using a strong password, using upper/lower case, numerical and punctuation, we have a character set of well over 50, so to combat this attack we simply all increase our passwords by one character. This will take security back to a state even higher than before this weakness was found.

      Hmm. Not really a fatal security flaw is it?

    6. Re:issue can be avoided by Anonymous Coward · · Score: 0

      You can do this on linux as well, just disable password auth. and enable key checking. Read the docs

    7. Re:issue can be avoided by Anonymous Coward · · Score: 0

      How are you supposed to get the RSA authentication key there in the first place?

    8. Re:issue can be avoided by prog-guru · · Score: 1

      Their client already does this, the issue is if I ssh into a machine, then ssh from there to another, then my key timings might be followed. My solution is to type asynchronously, pause for a random interval between each character, or each group of characters.

      --

      chris@xanadu:~$ whatis /.
      /.: nothing appropriate.

    9. Re:issue can be avoided by Anonymous Coward · · Score: 0

      Any "secure" method, as security literature would say. A normal human being would say floppy disk, or something similar.

    10. Re:issue can be avoided by jareds · · Score: 1

      My solution is to type asynchronously, pause for a random interval between each character, or each group of characters.

      What you actually want to do is type at a fixed rate (say, one character every two seconds exactly). Clearly, the attacker then gets no information about the password other than its length. Trying to be truly random is harder than just looking at a timepiece that gives seconds as you type your password.

    11. Re:issue can be avoided by stripes · · Score: 2
      Or with SSH by just not sending the password across the network at all. Using RSA euthentication completely nullifies this potential vulnerability.

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

    12. Re:issue can be avoided by stripes · · Score: 2
      most GUI implementations do. SecureCRT, MacSSH, etc. Most of the Linux lovers that I know (and myself) use the commandline version which has you enter your password in the standard way.

      Not really, even the command line ssh sends the ssh password in a single CMSG_AUTH_PASSWORD packet. The attack isn't talking about that password. It is talking about passwords you use after you are logged in. Say by running sudo, or ssh'ing to another host (maybe one that a firewall prevents reaching directly).

      You could avoid this by cut n' pasting your password, but that has other problems (like forgetting the password was the last thing in the buffer and pasting it somewhere you don't want it!), and is just ugly. The ssh client could buffer multiple characters, but it doesn't know when it should do that. Most of the time having that done would suck huge. The ssh client could also pad packet sizes, but that only helps so much.

      A real answer would change the ssh client, the ssh server, the ssh protocol, and anything that prompts for a password. Even if you assume that "anything that prompts for a password" all uses libc's getpass that is still a whole whole lot of work.

      What would the change do? It would have getpass do a tty ioctl letting the master side of tty know we are in "read password mode". The master side of the tty would be sshd in this case, it would send a new ssh message to the client asking for all keys typed to be buffered until the end line char, interrupt char, or other special control chars are typed, and transmit the whole buffer. The ssh client's role should be obvious.

      Come to think of it, that sounds alot like the telnet line mode, so maybe the tty driver has an appropriate mode, but a quick look turned up nothing.

    13. Re:issue can be avoided by Anonymous Coward · · Score: 0

      Say by running sudo, or ssh'ing to another host (maybe one that a firewall prevents reaching directly).


      You can always use RSA authentication to avoid the attack when ssh'ing to another host. The authentication agent (try "man ssh-agent") can be used so that the passphrase used for protecting the RSA keys is not sent to the network, but only used locally at the workstation you're sitting at.
    14. Re:issue can be avoided by rgmoore · · Score: 1

      That's great, but how do they know when somebody is entering a password locally? It's not as though they can read all your keystrokes and tell exactly what you're doing. The only way they could do so is if they're also logged on to the remote computer so that they can process monitor and see exactly what you're doing. Otherwise they won't know whether you're typing in a password or replying to a message on /. in Links. If they've already got access to the machine, they're much more likely to be able to find a local root compromise than brute force a good password using key timings.

      That's not to say that they should just ignore the problem. With a little bit of cleverness they could minimize the problem. Some of the approaches already mentioned- adding jitter to packet sending times, sending multiple characters in a single packet if they're being typed quickly, etc. could make the technique pretty much hopeless. But let's face it, it's already pretty hopeless, since the attacker doesn't have an obvious way of finding out when and where you're sending a password during the session in the first place.

      --

      There's no point in questioning authority if you aren't going to listen to the answers.

    15. Re:issue can be avoided by Anonymous Coward · · Score: 0

      That's great, but how do they know when somebody is entering a password locally? It's not as though they can read all your keystrokes and tell exactly what you're doing.

      You are being silly. Timing analysis can be used on anything the ssh user types in, not just passwords. It's pretty simple to guess what the user is doing by simply looking at the traffic profile.

      Besides, when the remote application is in normal interactive mode it echoes back all characters it receives (so that they are shown on the user's terminal). When it's reading passwords, it's not writing anything to the terminal until the user presses enter. So, if the adversary sees packets going to one direction but sees no answers, chances are the user is typing in a password.
    16. Re:issue can be avoided by jrp2 · · Score: 1

      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 it appears they are focussing on the initial login. It is much easier as they know where in the stream to look. Trying to capture a sudo, etc. would be very difficult as you would need to analyze the entire session stream (that is almost certainly intermixed with writing emails, scripting, coding, etc.) and look for repeating patterns (and that assumes you are entering the password alot for various things).

      Or loging into another machine.

      Yes, they do address that. But now that involves them having a very, very (almost too) convenient location from which to sniff, twice (or they are sniffing from your machine itself). Using switched networks (super common) and decent physical security will make this really hard. Also, if you use RSA style auth on this operation too, you have circumvented it again.

      I think the original posters statement that RSA authentication is the way to short-circuit this potential vulnerability is correct. Perhaps the use of the word "nullify" is a bit strong, but it sure makes an extremely difficult task even more difficult (perhaps approaching impossible). I have to be honest, I have always found RSA auth annoying, but this vulnerability has perhaps convinced me that it is the right way to go.

      --
      The only athletic sport I ever mastered was backgammon - Douglas William Jerrold
    17. Re:issue can be avoided by Anonymous Coward · · Score: 1, Informative

      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.
    18. Re:issue can be avoided by stripes · · Score: 2
      That's great, but how do they know when somebody is entering a password locally? It's not as though they can read all your keystrokes and tell exactly what you're doing. The only way they could do so is if they're also logged on to the remote computer so that they can process monitor and see exactly what you're doing. Otherwise they won't know whether you're typing in a password or replying to a message on /. in Links.

      That's what I thought before I read the paper. However you can guess when passwords are typed. One big hint would be lack of an echo. Sure, that might be someone typing a long vi command sequence, or the far end being slow, but the traffic information is only used to help guess passwords, it isn't relied on to actually be 100% accurate!

    19. Re:issue can be avoided by stripes · · Score: 2
      You can always use RSA authentication to avoid the attack when ssh'ing to another host. The authentication agent (try "man ssh-agent") can be used so that the passphrase used for protecting the RSA keys is not sent to the network, but only used locally at the workstation you're sitting at.

      I didn't know ssh-agent on machine A could help you log into machine C from machine B. How does that work given that ssh-agent only binds to a unix domain socket (single host IPC)? Does ssh magically tunnel it? I didn't see anything in the RFC about that when I implemented my ssh client!

      It definitely didn't work magically for me when I logged into my work account from my home machine and tried to have it RSA authenticate to my SourceForge account -- it does work from my home account.

      Lastly, what makes you think that the kind of wanker that can't trust ssh and makes you bounce through a firewall is going to leave RSA auth on? Eh?

    20. Re:issue can be avoided by Anonymous Coward · · Score: 0

      Knowing the exact length of the password eliminates all potential passwords both shorter and longer. So this does narrow a brute force attack considerably.



      Weak passwords have been a problem for a long time. The strongest would be long sequences of random numbers and letters, and different for every login/platform combination. Unfortunately, no one would be able to remember them all and they'd have to write them down. Add in the requirement that they be memorizable, and you get shorter passwords with memonic characteristics reused in many places. And lots of people use weak passwords even with these criteria. Sigh.

    21. Re:issue can be avoided by vph · · Score: 1

      > Does ssh magically tunnel it?

      Yes it does... see manual page for option -A.
      Forwarding works (at least) when protocol version
      1.5 is used.

    22. Re:issue can be avoided by rsimmons · · Score: 1

      That will work for the initial connection, but what about further connections from then on? Those username/password combos will be vulnerable.

  5. Is it really easier...? by frleong · · Score: 1

    Unless TCP/IP sends exactly one character in each packet, I wonder how the attacker can guess the password by the keyboard latencies.

    --
    ¦ ©® ±
    1. Re:Is it really easier...? by Anonymous Coward · · Score: 1, Informative
      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.

    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. Re:Is it really easier...? by frleong · · Score: 1

      Well, if anything, this only proves that telnet and login are the culprit (due to the way they accept passwords), not SSH. For paranoids, it is necessary to find ways to avoid normal telnet authentication methods.

      --
      ¦ ©® ±
    4. Re:Is it really easier...? by numo · · Score: 1

      TCP waits for some time, whether it can stuff more bytes into the current packet, saving bandwidth - as far as I remember it is called Nagle algorithm and the usual timeout is 200 milliseconds with the maximum of 500 msec.

      The overwhelming majority of people knowing important passwords should be able to type two to three characters in a 200 msec window and the whole password in 500 msec, making this hole less exploitable :-)

  6. major problems. by sucko · · Score: 0
    Slashdot has suffered several major problems in the last week, as recent as yesterday, without so much as a peep from the maintainers of the site.


    Why the silence?


    I wonder who is taking the ad banner's bait to "Hire a Superstar" from VA when these guys can't even get a dopey message board up and running, much less a real web application.

    --

    -linux... they can't *give* that shit away.

    1. Re:major problems. by Anonymous Coward · · Score: 0

      The silence is due to that fact that they still don't know how to fix the problems.

      I'm sure we can expect some self gratifying explanation *after* the issues have been resolved.

      Rememeber the router fiasco last month?

    2. Re:major problems. by sucko · · Score: 0

      While I don't find it hard to believe that they still don't know how to fix the problem, I think they should give a status update.
      I spent 5 years or so as a developer for a consulting firm. The first rule was no communication was bad communication. Tell us what's happening!

      --

      -linux... they can't *give* that shit away.

    3. Re:major problems. by Anonymous Coward · · Score: 0

      Hey Simon, Stevejack is wondering why you won't return his phonecalls....

  7. We all know your password by DrD8m · · Score: 1

    Your password is:
    god

    Everyone knows it.

  8. Uh-oh [Like a certain S. NOLAN] by Anonymous Coward · · Score: 0

    The new Slashcode is failing AT ALL TIMES.

    How are you gentlemen!!

  9. This kind of attacks are useless by DrD8m · · Score: 1

    Because I always cross my hands when I type my password, and I do it following my favorite song rithm.

  10. Solution already exists. by Anonymous Coward · · Score: 2, Interesting

    There already is a solution to this. By using a buffer and a timer you can get multiple characters in a packet. This technique is used in the SNA session environment that utilizes emulators.

    Basically, keystroke input is placed in a buffer. The buffer sends its data when the buffer is full or when a buffer timer has expired. If you type very slowly, one character at a time is sent. However, if you type normally several characters are sent in each packet.

    The only drawback with this technique is that it can increase latency. If the input is only a single character, as would be the case in selecting a menu option, the user will experience latency as they wait for the timer to expire and send the keystroke. To reduce the latency to a minimum it becomes neccessary to very carefully adjust the buffer size for your particular application. Too small a buffer and the ability to guess password length still exists. Too large a buffer and latency becomes unaceptable.

    1. Re:Solution already exists. by Grail · · Score: 1

      You're talking about the Nagel Algorithm. It's described in RFC 896.

  11. I would think it's easy to beat the key-count by Anonymous Coward · · Score: 0

    By padding every packet (or login, or whatever) up to a mandatory size (say, 512 bytes of random data), and not sending the username or password until you hit 'return.'

    This, I think, would easily prevent people from findind out how long the password really is...

  12. Huh? by MfA · · Score: 1

    Just get rid of the notion that it has to be 100% like a shell just with a secure communication channel... if you md5 the password locally there is no problem.

    1. Re:Huh? by Anonymous Coward · · Score: 0

      Can you explain what your talking about...generally the password is hashed...or are you saying hash the password then ssh it then sen d it over the wire ...?

    2. Re:Huh? by Derek+Pomery · · Score: 1

      That's what I thought when I read this.
      The solution is trivial.
      Establish secure channel/determine remote server SSH version.
      If the server is older version, report the potential for vulnerability.
      else
      Grab the whole password, and send it over the secure channel all at once.
      I wouldn't hash it locally, because then you have to figure out what remote hashing algorithm is (crypt, md5, sha1...) since the channel is secure, easier to send it all at once. And in a large, uniform size packet to make guessing the length of the password also impossible.

      --
      -- perl -e'print pack"H*","6e656d6f406d38792e6f7267"' /. ate my old sig. Bastards.
    3. Re:Huh? by CoughDropAddict · · Score: 2

      Grab the whole password, and send it over the secure channel all at once.

      SSH already does this. The issue is NOT NOT NOT with the initial password to establish the connection, but with passwords that you type DURING YOUR SESSION (say, for sudo).

    4. Re:Huh? by Derek+Pomery · · Score: 1

      The article certainly did not emphasize that at all. I'll take your word for it though, until I have some time to check out SSH.com.

      If that is the case, then I don't really see any obvious solution, apart from an escape sequence to turn on line at a time, or keystroke at a time sending.

      Besides, if what you're saying is true, then this is really not very helpful as an exploit. I'll be on the server, sometimes for hours. I could be typing "cd /tmp" just as easily as "mysecretpassword" . How are they supposed to know what data is important? For that matter, why not simply not use sudo or su while on an ssh connection? Or heck, deny your priveleged accounts outside access. Most people do that anyway...
      Granted, orginal poster said, fake data could be injected, but it doesn't seem serious enough for that.

      --
      -- perl -e'print pack"H*","6e656d6f406d38792e6f7267"' /. ate my old sig. Bastards.
  13. I don't put a lot of stock. by Outlyer · · Score: 1, Troll

    Lest we forget, SSH communications is a commercial vendor, most of which have a notorious reputation for discounting the severity of vunerabilities. Sorry guys, but I'd have a lot more faith in hearing Theo from OpenBSD talk about security implications than a company that sells the "sizzle" of security (albeit with a decent product)

    When's the last time you heard a major vendor acknowledge a severe hole was actually severe. They have to worry about the lawsuits, and anything they say could be used in a class action, so while this particular threat isn't outright horrifying, it's likely worse than the spin it's getting from ssh.com.

    --
    ----------------- "I have a bone to pick, and a few to break." - Refused -------------------
    1. Re:I don't put a lot of stock. by Reality+Master+101 · · Score: 2

      When's the last time you heard a major vendor acknowledge a severe hole was actually severe.

      Um, how about Microsoft and Code Red, which incidently was patched months before the Code Red outbreak.

      --
      Sometimes it's best to just let stupid people be stupid.
    2. Re:I don't put a lot of stock. by thrig · · Score: 1

      SSH communications taking a stand and recognizing the issue is a far cry from them invoking the DMCA and getting the impudent hackers tossed in jail.

      This might have something to do with SSH being an open standard, and not the good will of the company, though...

    3. Re:I don't put a lot of stock. by jeffy124 · · Score: 1

      When's the last time you heard a major vendor acknowledge a severe hole was actually severe

      Microsoft on that IIS hole that gave way to Code Red

      --
      The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
  14. Ha, they won't get me!!! by chris.bitmead · · Score: 1

    They won't get me, I'm using a Dvorak keyboard.
    That will throw them off the track.

    Increase computer security - use Dvorak!

  15. Yes, SSH.com's product works fine with OpenSSH by Raetsel · · Score: 3, Informative

    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!

    --

    "...America's great minds of today, teaching America's great minds of tomorrow. Poor bastards." -- A Beautiful Min
  16. Um... by Scoria · · Score: 1

    Impractical? Not with a determined group of people bent on breaking in.

    People will try anything if they want something bad enough. These people don't factor in the motivation of some groups.

    Just MHO...

    --
    Do you like German cars?
  17. OpenSSh - no problem by cehf2 · · Score: 3, Interesting

    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.

    1. Re:OpenSSh - no problem by jareds · · Score: 3, Informative

      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.

    2. Re:OpenSSh - no problem by jimmcq · · Score: 2, Informative

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

    3. Re:OpenSSh - no problem by Anonymous Coward · · Score: 1, Insightful

      TCP segment, not packet.

    4. Re:OpenSSh - no problem by fanatic · · Score: 2

      And how is the cracker supposed to know this is happening?

      --
      "that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
    5. Re:OpenSSh - no problem by Anonymous Coward · · Score: 0

      The password isn't echoed back, which is a big hint that it's a password.

    6. Re:OpenSSh - no problem by David+Price · · Score: 2
      I wouldn't be surprised if a determined cracker could make it out from packet traffic. Let's say you're looking for someone su'ing to root; this behavior has a fairly established pattern:
      • It may occur very soon into the session - if you're logging in to do system maintenance, the su command may be the very first thing that you type.
      • It follows a fairly well-timed pattern; the su command is three typed characters (s, u, return), each of which is echoed back to the user's terminal, then a glob of data ("Password: "). Then there are some characters sent at a typing cadence, but not echoed back to the terminal (this alone might be enough to isolate passwords).

      It probably would not be hard at all to isolate packets from an SSH dump in order to determine exactly which ones constitute a password. It's trivial, from this, to determine the length of the password. You also have timing information which, if accurately collected and combined with a profile on the typist, might allow you to refine a brute-force search considerably (the paper's researchers apparently were able to speed up their brute force crack by a factor of fifty - if you had a profile of the typist on file, you might be able to improve that by an order of magnitude or two.)


      Another vulnerability stemming from having touch-type profiles: during World War II, individual telegraph operators could be recognized by their "fist," the characteristic way they typed their messages. It's probable that individual computer users could be similarly recognized and automatically profiled.

    7. Re:OpenSSh - no problem by frleong · · Score: 1

      But, then how does the hacker know that your are typing a password at su prompt or simply typing an e-mail?

      --
      ¦ ©® ±
    8. Re:OpenSSh - no problem by jareds · · Score: 1

      This is answered in dozens of other threads: it's just about the only time that the server doesn't send responses to the keystrokes.

  18. If you care, use key-based authentication! by DougM · · Score: 2, Informative


    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.

    1. Re:If you care, use key-based authentication! by CoughDropAddict · · Score: 2

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

      STOP IT!! PLEASE LEARN SOMETHING ABOUT WHAT YOU'RE TALKING ABOUT BEFORE YOU START SPEWING MISINFORMATION ABOUT HOW TO FIX IT!!

      Public key authentication will help you ZERO to ward off this kind of attack. The issue is NOT about the password that establishes a connection, it is about passwords typed DURING the connection (like for sudo).

  19. Microsoft? by Anonymous Coward · · Score: 0

    sounds like what Microsoft said about the hotmail "vulnerability"

  20. Quick solution by CyberBry · · Score: 2, Informative

    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 ;)

    --

    ----
    Bryan Samis
    http://www.thesamis.net
    1. Re:Quick solution by jtdubs · · Score: 2

      Or better yet, DO type it fluidly. I've typed my password so many times that my fingers just flow from key to key. I type around 160wpm anyway. The timings are no different between a letter and a number than between two letters. Its 14 characters and takes me about 0.4 seconds. Just TRY and reconstruct the password from those keytimings...

      Justin Dubs

  21. baloney by Anonymous Coward · · Score: 0

    Every major issue I've taken to SSH in the last year have been added to the product suite.. There a good product, a good company with good intentions. While everyone was saying long ago that they were just getting rid of sshv1 to make money they were say NO ITS FLAWED...

    And btw it Isn't a major vulnerability...take a look at. Oh and the ssh.com client does buffer...

  22. send ghost characters by friscolr · · Score: 2
    Surely you've seen that really annoying javascript which creates images around your mouse whenever you move it? What about having something similar to that for ssh - create ghost characters whenever you type in one character?

    Let's say you enter one char of text, your client recognizes this and begins to send out more bytes of data to provide cover for your char. This cover should last for a random period of time after the initial key press (say, 1-5 seconds) and should consist of a random number of packets sent with timings from 0 to the average timing between key presses. The packets have to be something predetermined by the client and server so that the server knows to ignore these packets. Any other packets the client sends which happen to match this predetermined packet will have to be escaped somehow.

    so when i go to type in
    passwd
    the client sends these packets:

    p
    (cover packet)
    (cover packet)
    a
    (cover packet)
    s
    (cover packet)
    (cover packet)
    (cover packet)
    (cover packet)
    s
    (cover packet)
    (cover packet)
    w
    (cover packet)
    (cover packet)
    (cover packet)
    d
    (cover packet)

    This should destroy an attacker's ability to determine the timing frequencies between your keypresses. The length of the text you've entered may still be determined, but only within a certain range, provided the cover packets last for long enough after a single keypress. That is, if the cover packets last up to 3 average key presses in length, then the attacker will know the length of the string you entered +-3 characters.

    --

    -f
    www.blackant.net

    1. Re:send ghost characters by jtdubs · · Score: 2

      Better yet. The hole duration of the connection, even when we aren't typing. The ssh client should flood the network with dummy packets to making sniffing impossible. The packets should be as large as possible, maybe 64k, just to keep everyone on their toes.

      Then the ssh client should check the weather and display it in a window on you screen. But first it should open lots of wake windows with dummy weather information so anyone walking by your cubicle can't find out what the REAL weather is. Muahhaha.

      Or, better yet. The easy way. Just group characters into blocks before sending them and send the blocks at a regular interval. If 8 keys have been typed in that interval, send 'em all. If only one, send just that one. Encypher the block so no one can tell how many keystrokes are in it. Send them every .1 seconds or whatever. Just block 'em. Done. Problem solved.

      Justin Dubs

    2. Re:send ghost characters by PhiRatE · · Score: 2

      The code necessary to resolve this problem is literally a 4 line patch to openssh. I'm not kidding, I did it myself, they even have comments in most of the places you need to put it. I added a -z option which creates randomised network noise, uses from 400 to 1200b/s of packets that look just like password character packets. The support is in the protocol already, it requires no modifications to sshd, and it works fine. The only issue is the additional use of bandwidth.

      This, of course, is the problem that everyone is interested in. Its an easy problem to solve, 4 lines, but not an easy problem to solve nicely, in a way that won't result in an increase in the amount of bandwidth used by an ssh application.

      I don't believe its really worth worrying about. If you're really paranoid, you should add a patch like mine or run over freeswan or something. In general, its not a script-kiddie vuln.

      --
      You can't win a fight.
  23. Another solution by Falsch+Freiheit · · Score: 3, Insightful
    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)

    1. Re:Another solution by Anonymous Coward · · Score: 0
      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 at the end of my password.

      The issue is not, and never was, the initial password, which is always sent in only one chunk in every SSH-2 protocol implementation. The problem is when passwords (or whatever) are typed in during a connection, say when using sudo or when ssh'in to another machine using password authentication instead of something more sensible, like RSA authentication with ssh-agent.
    2. Re:Another solution by jimmcq · · Score: 1

      there's no packet sent for each stroke of my password, one packet is sent when I hit at the end of my password

      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'.
      Yes, I posted this already in reply to another, but people keep modding up these misleading posts.
    3. Re:Another solution by Xn · · Score: 1

      the keystroke timing comes into play after you're authenticated, but then you su or ssh into another box (if you're not using rsa/dsa keys with key forwarding)

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

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

  26. Mostly Nonsense by fanatic · · Score: 3, Interesting

    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.

    --
    "that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
    1. Re:Mostly Nonsense by bartc · · Score: 1


      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.

      http://www.openwall.com/advisories/OW-003-ssh-traf fic-analysis.txt

      See the part about "Interactive session weaknesses".
  27. There is some sense in that. by Petrus · · Score: 1

    I always SSH as a user and then su root and type the password. SSH should have ghost characters that guarantee, that some packets are send in regular interval with some nonsense and typed characters should be synchronized to that rate.

    It should not be much of problem to do that and perhaps it does not require any change in the protocol spec.

    Even if the password remains secret, why should anybody be able to read the typed text?

    Petrus

  28. a REAL, INTERESTING solution possibility by CoughDropAddict · · Score: 2

    It's been mentioned that this could be solved by simply buffering X keystrokes before sending, and then send them all at once. This works, but as the poster mentioned, the latency it would introduce would be very annoying.

    A better, modified version of this solution would buffer data ONLY when you're typing in a password of some sort. But who wants to manually tell SSH that they're typing in a password every time they run sudo or su?

    The solution: while an SSH session is in progress, LD_PRELOAD a library that intercepts whatever library/system call disables echoing on a terminal (I don't know enough about terminals to know what call this would be). Then, enable buffering whenever the terminal echo is disabled. Problem solved!

    If it's not a system or library call that disables echo, then just monitor for the escape sequence that does it instead.

    You would of course pad the buffer so that you don't give away the length of the password.

  29. A simple fix by sjames · · Score: 2

    If the client is modified to insert a random delay between keystrokes, the attack becomes MUCH harder to pull off.



    The attack is not so much an attack against SSH as it is a general attack on crypto terminal sessions. IIRC, this form of attack was originally suggested as a way to intercept numeric keypad entries based on EM radiation from the keypad itself.


  30. Problem with implementation not protocol by matrix0040 · · Score: 1

    well the problem is with the implementation not the protocol. SSH protocol has a provision to send in null data. so if properly implemented then this defeats the attack.

  31. Just a minor point by drugfrog · · Score: 1

    how about we just ignore it.

    it seems to me that far too much processing and logging is needed to get a small amount of information which only narrows down the list of posibilities. Also how many people run su or sudo on a machine? For security it should be only one. And also for security you shouldn't re-ssh off an exposed machine, but if you want to allow this you should use RSA keys.

    Then we have the fact that the evesdropper has no clear way of knowing that anyone has input a password, so he has to analyse every keystroke and every response and try to find the input 's u' followed by return and then he has to take it on blind faith that it is 'su' and not 'di', 'sj', 'sn', 'd8', 'ab' or even 'u2' as these are all about the same spacing apart on the keyboard (for us non-touchtypists out there).

    But then just suppose thay did get a password for say an ssh connection or even narrow down the posibilities what good would it do. They would have no idea where the connection was going to, but he could try the same thing with the ip/domain name, still on faith, so he now has to try and brute-force his way through different items first find the server, then find the username, then find the right password. Now there is the posibility that the username and password would be the same on both servers but that is why you would use the RSA keys to authenticate.

    All in all no real information is gained. All you gain is data that if coupled with sociological, personality and typing profilles could lead to a security breach but would need to be focused on the client end of the connection and so would have much further reaching consequences as this is analisys on the Bletchly Park scale of things