On 2014-11-18, Philippe Cerfon <philcerf@xxxxxxxxx> wrote: > 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. Or rsync -z, or people building their own compression layer, etc. > 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)? OpenSSH already adds the minimum random padding required: "Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || random padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding." https://tools.ietf.org/html/rfc4253#section-6 I don't know how much this interferes with compression oracle attacks in practice. > 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. I think SSH is the wrong layer to address this. People need to be wary of building application protocols that combine an authentication token (cookie, password) and known plaintext into frequent queries. The vast majority of SSH compression uses aren't concerned by this. -- Christian "naddy" Weisgerber naddy@xxxxxxxxxxxx _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
