|| ||johan beisser <jb-AT-caustic.org>|
|| ||"Philip Guenther" <guenther-AT-gmail.com>|
|| ||Re: Patching a SSH 'Weakness'|
|| ||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.
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
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.
to post comments)