can compression be safely used with SSH?

[Christian Weisgerber]

On 2014-11-18, Philippe Cerfon <philcerf at gmail.com> wrote:

> Now the following is not really that much relevant for the our
> scenario, where all nodes are in one intranet, but I was speculating
> with a colleague of mine, whether this (and SSH in general) could be
> abused for CRIME/BREACH like attacks.

These attacks apply when the adversary can monitor your traffic and
you mix secret data with public data injected (or at least observed)
by the attacker.  This results in a compression oracle: the size
of the compressed packet can be used to infer matches between the
secret and public data and thus leaks secret information.

> Now I'm aware that at least OpenSSH uses the delayed compression so
> it's not so easy as with webservers, but when you look at how we use
> it - it should be quite simple for an attacker to inject some chosen
> plain texts in our logs (e.g. logs from a webserver).

Yes, but do your logging connections carry any secrets?

> So what exactly does that mean? Can it be used to get more knowledge
> on the used session keys?

No.

> Or can it be used to possibly decrypt that block of data which
> contained the plaintext?

Not decrypt, but deduce.  The attacker doesn't need the ciphertext
at all, they just need its size.  This allows them to make inferences
about the secret plaintext.

> Of course in SSH it wouldn't be that easy, where one might have something like:
> GET /fobar?password=secret&chosenPlainText=gotcha

That is a great example for a construct that is vulnerable to this
sort of attack.  The underlying encryption--IPsec, SSL, SSH,
whatever--doesn't matter.

> So I could be stupid and have a log format in Apache httpd which is like:
><date> myrootpassword=iamdumb <request URI>
>
> Now in the above scenario and attacker that could eavesdrop our log
> collector's connections, could also make arbitrary requests to our
> company's webserver, thereby change places chosen plaintexts <request
> URI> and by the compression deduce the password.

Yes.

> As I've said, the whole thing is probably no real world thread. I'm
> rather wondering whether SSH would be in principle vulnerable too

It is.  Strictly speaking, SSH proper isn't, but your overall
protocol construct that uses SSH as encryption layer is vulnerable.
Banning SSH's compression doesn't solve this problem: If you compress
the data yourself before sending it over SSH, you're vulnerable
just the same.  Anything with a layering like this

   +------------------------------+
   | secret |  injected plaintext |
   +------------------------------+
   |         compression          |
   +------------------------------+
   |          encryption          |
   +------------------------------+

is affected.

> I found http://thread.gmane.org/gmane.network.openssh.devel/20016 in
> the archives, which implies that the delayed compression would make it
> secure.

No, this only refers to SSH's password authentication.  Delaying
compression until after authentication, as zlib at openssh.com does,
means that the password isn't compressed, thus there can be no
compression oracle.

> a) So how would that prevent the basic idea of the attack as outlined above?

For data that you pass after authentication, it doesn't.

> b) Why would the non-delayed compression be insecure? Okay there might
> be a valuable secret involved (e.g. the passphrase) which is then
> compressed, but an attacker can likely not inject and chosen plain
> texts at that step of protocol negotiation between a valid client and
> the server?

Indeed, this is unlikely to be exploitable.

Delayed compression wasn't introduced to protect against this
(I think), but to guard against bugs in the compression code, like
a buffer overflow in the decompressor.  With delayed compression,
you can't attack the compression code unless you can authenticate,
and once you're authenticated, you can only attack an sshd child
process that has dropped permissions.

> And what would it help him, if the attacker on himself makes gazillion
> connections requests, altering e.g. the user- or algo names? Nothing
> valuable should have been sent to an unauthenticated client by the
> server at that stage.

Right.

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de