Bug#381973: [Pkg-cryptsetup-devel] Bug#381973: cryptsetup segfaults with unsupported keysize

[David Härdeman]

On Mon, Nov 20, 2006 at 11:42:13PM +0100, Jonas Meurer wrote:
>Hello Clemens,
>
>Debian bugreport #381973 reports that cryptsetup segfaults when an
>incompatible keysize is given as an option.

Actually I think it is whenever a keysize > 256 is used (and only when 
trying to unlock the partition, not when creating it).

>Later David Härdeman analyzed the following:
>
>> During "cryptsetup luksOpen" with the previously set 448 bit (56 byte)
>> key, we'll have the following call chain:
>>
>> main -> action_luksOpen -> crypt_job -> __crypt_luks_open ->
>> LUKS_open_any_key -> LUKS_open_key -> AF_merge
>> 
>> AF_merge is being called as:
>> AF_merge(AfKey,mk->key,mk->keyLength,hdr->keyblock[keyIndex].stripes);
>> 
>> mk->keyLength is here (correctly) set to 56, and mk->key is a statically
>> allocated 32 byte buffer (defined as part of struct luks_masterkey in
>> luks.h).
>> 
>> This will lead the last call to XORblock in AF_merge to scribble 56 - 32
>> bytes outside that buffer, thus corrupting the stack and leading to
>> interesting crashes in unrelated places later.
>
>The simplest solution would be to check whether mk->keyLength is a
>multible of eigth and exit with an error message otherwise, correct?

If I understood the LUKS parts of the code correctly...it is written 
with the assumption that keysizes will not be > 256 bits. So the easiest 
fix would perhaps be to refuse to create > 256 bit keyed LUKS partitions 
for now...or fix the real limitation, but that requires more 
understanding of the code than I have time to gather right now.

>or would that break something?
>If not, it would be rather easy to fix, and i would love to see it
>fixed in debian etch.
>
>...
> jonas

-- 
David Härdeman