Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

SSH Taking Stand On Vulnerability 90

Posted by Hemos 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."
This discussion has been archived. No new comments can be posted.

SSH Taking Stand On Vulnerability More

SSH Taking Stand On Vulnerability

Comments Filter:
  • How is it with openssh?

    • 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!

  • So what.. (Score:4, Insightful)

    by eye.likeJava() ( 266735 ) on Sunday August 26, 2001 @08:18AM (#2217990)
    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..

    • Huh? (Score:1)

      by MfA ( 107204 )
      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.
      • 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.
        • 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).
          • 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.
    • 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

  • issue can be avoided (Score:2, Informative)

    by neodymium ( 411811 )
    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.
    • 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.

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

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

          • 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!

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

          • Re:issue can be avoided (Score:1, Informative)

            by 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.
    • 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").
      • 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.
        • 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.

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

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

    • That will work for the initial connection, but what about further connections from then on? Those username/password combos will be vulnerable.
  • Unless TCP/IP sends exactly one character in each packet, I wonder how the attacker can guess the password by the keyboard latencies.

    • Re:Is it really easier...? (Score:1, Informative)

      by 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...? (Score:5, Informative)

      by q[alex] ( 32151 ) on Sunday August 26, 2001 @09:20AM (#2218076) Homepage
      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

      • 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.
      • 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 :-)
  • Your password is:
    god

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

  • Solution already exists. (Score:2, Interesting)

    by Anonymous Coward
    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.

  • 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.
  • They won't get me, I'm using a Dvorak keyboard.
    That will throw them off the track.

    Increase computer security - use Dvorak!
  • 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...

  • OpenSSh - no problem (Score:3, Interesting)

    by cehf2 ( 101100 ) on Sunday August 26, 2001 @10:08AM (#2218161)
    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 (Score:3, Informative)

      by jareds ( 100340 )

      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.

    • Re:OpenSSh - no problem (Score:2, Informative)

      by jimmcq ( 88033 )
      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'.
      • And how is the cracker supposed to know this is happening?
        • 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.

    • Re:OpenSSh - no problem (Score:1, Insightful)

      by Anonymous Coward
      TCP segment, not packet.

  • If you are this paranoid then you would already be using public key authentication [openssh.com].

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

  • Quick solution (Score:2, Informative)

    by CyberBry ( 196935 )
    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 ;)
    • 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
  • 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.

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

  • Another solution (Score:3, Insightful)

    by Falsch Freiheit ( 7780 ) <freiheit@[ ]il.com ['gma' in gap]> on Sunday August 26, 2001 @11:30AM (#2218329) Homepage
    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)


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

  • New Technique realeased (Score:4, Funny)

    by gad_zuki! ( 70830 ) on Sunday August 26, 2001 @11:43AM (#2218372)
    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 (Score:5, Informative)

    by Dr. Blue ( 63477 ) on Sunday August 26, 2001 @11:46AM (#2218385)
    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 (Score:3, Interesting)

    by fanatic ( 86657 ) on Sunday August 26, 2001 @12:52PM (#2218621)
    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.



    • 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 [openwall.com]

      See the part about "Interactive session weaknesses".
    • 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
  • 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.

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


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

Slashdot Top Deals

Sentient plasmoids are a gas.

Close