can compression be safely used with SSH?

[Philippe Cerfon]

Hi Christian.

Thanks for your answers!


>Yes, but do your logging connections carry any secrets?

No, sure, as I've said, it's more a theoretical thinking based on the
paradigm "everything is secret"


>> 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.

Of course it works with any protocol, I didn't meant to blame SSH.


>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.

Sure, but the manual case should be much harder to exploit, unless
there is some automatic compression that happens which attacker knows
about and where chosen plaintext can be injected.
Of course this is exactly what could happen in an example similar to
mine, SSH compression disabled, but regularly copying logrotated and
gzipped files from the hosts to the collector host.
But there an attacker would have basically no idea which of his chosen
plaintexts went into which file, which portion of the file he's
currently seeing and so on.
This may very well render the attack impracticable, right?

Perhaps this goes a bit off topic, but are there any general
countermeasures being developed against these kinds of attacks, which
could then also used with SSH? Like salting the length of transmitted
packets with some 1-30 random bytes (I mean for every packet using a
different salt length)?


>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.

I see.


Again, the following is rather theoretical:

I usually try to educate my colleagues to use better crypto
respectively care about security, so I wondered whether I could
whitelist SSH level compression for certain accounts on the server
side.
Of course this still doesn't solve the principal vulnerability of any
manually compressed data (being composed of chosen plaintext + secret
data) but I'd guess that this is anyway far more difficult to exploit
and preventing at least only one of them is better than nothing.

So I imagined that I could do something like:
Compression no
in my global sshd_config but add a
Match User sue,larry
   Compression delayed

Assuming that I've educated sue and larry about the attack, and thus
they wouldn't use ssh to transfer possibly injected data (like logs)
when compression is on, they would still be allowed to do so.
My nagios-probe user however, would be denied per the global default.

Unfortunately it seems that Compression cannot be used inside Match :-(


Regards,
Philippe