Hello. At work we collect logs (via ssh) from all kinds of hosts on one central node which has no connection to the internet and is tried to kept secure. The idea is, as you can imagine, that in case of a compromise we'd have at least all the logs up to the break without any forgeries. The logging is done continuously and compression is used. 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. 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). As war as I understood, the idea of CRIME and friends was that one knows the parts of the plain text, sees how the ciphertext changes and can then use the change of length in cryptoanalysis. So what exactly does that mean? Can it be used to get more knowledge on the used session keys? Or can it be used to possibly decrypt that block of data which contained the plaintext? Of course in SSH it wouldn't be that easy, where one might have something like: GET /fobar?password=secret&chosenPlainText=gotcha So there is not such direct way to extract a secret as it was made possible in an attack like CRIME, but yet it may theoretically be possible to get out something useful, or wouldn't it? 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. 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 I found http://thread.gmane.org/gmane.network.openssh.devel/20016 in the archives, which implies that the delayed compression would make it secure. a) So how would that prevent the basic idea of the attack as outlined above? 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? 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. Regards, Philippe.
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=gotchaThat 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 tooIt 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
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
>I think SSH is the wrong layer to address this.Sure,... as it was said, it's a general problem. But I'd guess the more systematic compression is deployed (e.g. on a protocol level) the easier it gets to exploit.>People need to be >wary of building application protocols that combine an authentication >token (cookie, password) and known plaintext into frequent queries.Well most of our people here using SSH aren't wary of very much - one can basically be happy if they check fingerprints. ;-)>The vast majority of SSH compression uses aren't concerned by this.Sure, nevertheless, I've had a short glance at the source code: Wouldn't it basically work to change in servconf.c: { "compression", sCompression, SSHCFG_GLOBAL }, to { "compression", sCompression, SSHCFG_ALL }, and when it was actually set in Match section, bail out with an error when "yes" was used? Since delayed compression happens only after authentication, this should make it possible to use it with Match User. Or do I miss something? Sincerely, Philippe
Hello.>Even if delayed compression is only activated after authentication, >the the fact that delayed compression will be used has already been >negotiated before authentication and can't be changed retroactively.Couldn't the server simply abort a connection in the case that it sees that the negotiated compression algorithm doesn't fit, once the user is determined? Bailing out with some error message, before the client could have done anything. This is perhaps not the cleanest way, but in practise it should do quite well, and the same could possibly be done to allow many others of directives to be used inside Match, for which this is currently impossible. One could for example restrict certain authentication methods (or their options) to certain users/groups. Regards, Philippe
On Sat, 22 Nov 2014, Philippe Cerfon wrote:> Hello. > > >Even if delayed compression is only activated after authentication, > >the the fact that delayed compression will be used has already been > >negotiated before authentication and can't be changed retroactively. > > Couldn't the server simply abort a connection in the case that it sees > that the negotiated compression algorithm doesn't fit, once the user > is determined? > Bailing out with some error message, before the client could have done anything. > > This is perhaps not the cleanest way, but in practise it should do > quite well, and the same could possibly be done to allow many others > of directives to be used inside Match, for which this is currently > impossible.Killing the connection if the client suggests the wrong option is quite hostile to the user. I don't think we'd want that. It's theoretically possible to force a rekeying after authentication with new options, but this is slow: several client/server round-trips plus the potentially very slow key exchange crypto. IMO it's too slow and confusing to be worth implementing.> One could for example restrict certain authentication methods (or > their options) to certain users/groups.OpenSSH has supported this for years; see the documentation for 'Match' in sshd_config(5). -d