Re: Patching a SSH 'Weakness'

On Sep 12, 2008, at 3:12 PM, Philip Guenther wrote:

> On Fri, Sep 12, 2008 at 2:05 PM, johan beisser <jb@caustic.org> 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.