|From:||johan beisser <jb-AT-caustic.org>|
|To:||"Philip Guenther" <guenther-AT-gmail.com>|
|Subject:||Re: Patching a SSH 'Weakness'|
|Date:||Fri, 12 Sep 2008 15:34:26 -0700|
On Sep 12, 2008, at 3:12 PM, Philip Guenther wrote: > On Fri, Sep 12, 2008 at 2:05 PM, johan beisser <email@example.com> wrote: > > This about security. Being realistic means *not* being optimistic > that extracting data will be "too hard", "too unlikely", "only > applicable to a subset of people [and certainly not me]", etc. Have > you not read enough papers that start with something like "It was > previously thought that attack [foo] was impractical for the following > reasons: [blah blah blah]. This paper demonstrates practical > circumstances under which those reasons fail or don't apply and the > attack succeeds"? Sure, against SSH1. http://www.openwall.com/advisories/OW-003-ssh-traffic-ana... The ACM paper was also published in 2001, same time frame. There's more padding (see the TCPDump output I provided) in SSH2. Also, take a look at what Damien Miller responded with: OpenSSH is applying extra padding. SSH2 is the default these days. I won't say it's impossible to do keystroke analysis, it's just going to be difficult to know if what two letters were typed and when. Frankly, I've given you ssh2 packet dump (i'll happily provide raw tcpdump output, if you want it). > As such, statements of "can't be done" that don't have hard data or > proofs attached are pretty much worth the electrons they were sent > with. You might not see how the published attack can be made > practical against you, but someone else will almost certainly see the > next link in making it so. The original posters didn't sound like > they were being overly sensationalist, just interested in cutting off > a possible avenue of attack *before* it becomes a problem. I'm not a mathematician, let alone a cryptographer. I don't have access to the latter, but I do to the former with a fair amount of ease. If you really want a proof.. look at the SSH2 protocol code yourself. The protocol is open, documented, and so far hasn't been proven vulnerable to the same analysis SSH1 was. Let alone the key interception problem in SSH1. > They're different types of attacks; they have different applicability. > Perhaps the timing attack can be done remotely, over a long period of > time, and therefore has a much lower risk of detection. Even better, > it may be possible to do it 'in bulk', where shoulder-surfing and > similar is much harder to parallelize. If someone can intercept gigabytes of interactive traffic, they're likely to get keys first, then decrypt session information after that. If you get enough traffic, you can do pattern analysis for keystrokes and output (oh, this is output from uh.. "ls -al" I think..), or you can do traffic analysis to recover the session keys, and possibly infer the host keys (egads, i hope not). Again, you'll need a fair amount of horsepower to do it. I just do not see keystroke analysis as a viable method of attack, let alone a likely one. Again, if you're worried about keystroke traffic analysis, pump random keystrokes through the same ssh tunnel. Multiplex the session and force a background session to use the same ssh tunnel and execute arbitrary remote commands interactively. It doesn't take much to throw off this kind of analysis.
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds