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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
