mod_session_crypto supports multiple SessionCryptoPassphrase keys. The
idea is that when decrypting a session you try one key after the other
until the decryption succeeds, assuming that the successful key is the
key that was used when the session was encrypted.
But this assumption obviously doesn't hold. I have a case where a wrong
(old) key successfully decrypts a session that was encrypted with a
different (new) key. This leads to a segfault in mod_session.c,
session_identity_decode() because the tokenization assumes valid data
when in this case it's just binary rubbish (one of the apr_strtok()
calls segfaults).
I "fixed" this by adding an additional sanity check to
mod_session_crypto.c, decrypt_string(), see the attached patch. Of
course this fix only works for cases where the seemingly successfully
decrypted binary rubbish contains 0x00 somewhere in the decrypted data.
Any ideas for a proper fix?
Sorry that I can't provide you with the actual session data since it
contains sensitive information (username and password).
--- mod_session_crypto.c.orig 2016-11-04 15:34:46.740015054 +0100
+++ mod_session_crypto.c 2016-11-04 15:36:02.407403627 +0100
@@ -321,6 +321,12 @@
decryptedlen += tlen;
decrypted[decryptedlen] = 0;
+ if (strlen(decrypted) != decryptedlen) {
+ ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ "decryption sanity check failed");
+ continue;
+ }
+
break;
}
