linux-kernel - [PATCH] cit_encrypt_iv/cit_decrypt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060820002346.GA16995@openwall.com>
Date:	Sun, 20 Aug 2006 04:23:46 +0400
From:	Solar Designer <solar@...nwall.com>
To:	Willy Tarreau <wtarreau@...a.kernel.org>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH] cit_encrypt_iv/cit_decrypt_iv for ECB mode

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.

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.

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.

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.

(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.

Thanks,

Alexander

View attachment "linux-2.4.33-ow1-crypto-ECB-Oops.diff" of type "text/plain" (1587 bytes)