Slashdot Mirror
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."
How is it with openssh?
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#..
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.
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.
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
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
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.
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.
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.
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
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
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)
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
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....
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
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).
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.