On Sun, Aug 20, 2006 at 04:23:46AM +0400, Solar Designer wrote:> Willy and all,> > Attached is a patch (extracted from 2.4.33-ow1) that works around an> unfortunate problem with patch-cryptoloop-jari-2.4.22.0 (and its other> revisions). I am not sure whether the problem should be worked around> in the main Linux kernel like that, but this is what I did in -ow> patches for now.

You definitely provide interesting cases :-)

> Basically, crypto/cipher.c: crypto_init_cipher_ops() in Linux 2.4 (I did> not check 2.6 for this) did not initialize cit_encrypt_iv/cit_decrypt_iv> for ECB mode at all. While IV makes no sense for ECB mode, I would> think that a safer approach would be to initialize those pointers to> nocrypt_iv.

That's what I thought after reading the code too. BTW, 2.6 does notinitialize the pointers either.

> patch-cryptoloop-jari-2.4.22.0 calls cit_encrypt_iv/cit_decrypt_iv> directly, ignoring their return value. Thus, when these pointers are> not initialized (as they are not in vanilla Linux 2.4.33) and we request> ECB mode encryption via cryptoloop (a bad idea, but anyway), the kernel> most likely Oopses. When these pointers are initialized to nocrypt_iv> (due to a "correct" patch), there's no Oops, but the kernel leaks> uninitialized memory contents via the loop device (that's because> patch-cryptoloop-jari-2.4.22.0 ignores the -ENOSYS returns). Neither> behavior is any good.

Indeed, that's bad too.

> The attached patch actually defines ecb_encrypt_iv() and> ecb_decrypt_iv() functions that perform ECB encryption/decryption> ignoring the IV, yet return -ENOSYS (just like nocrypt_iv would).> The result is no more Oopses and no infoleaks either.

Can the cryptoloop patch use CRYPTO_TFM_MODE_CFB or CRYPTO_TFM_MODE_CTRand so be redirected to nocrypt() which will leave uninitialized memorytoo ?

> (Yes, I understand that ECB mode should be avoided and that this> cryptoloop patch does not address watermarking. But the security of> block device encryption offered by cryptoloop is irrelevant to the> point that I am making.)> > Opinions are welcome.

I wonder whether we shouldn't consider that those functions must atleast clear the memory area that was submitted to them, such asproposed below. It would also fix the problem for potential otherusers. I don't think we need to check whether dst is valid giventhe small amount of tests performed in crypt().