Re: crypsetup segfaulting during luksFormat

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Milan,

On Thu, 2010-07-08 at 17:11 +0200, Milan Broz wrote:
> On 07/08/2010 04:29 PM, Sven Eschenberg wrote:
> > Hi Milan,
> > 
> > Even worse, actually byte swappig is done to store the int in a big
> > endian manner, unfortunately, since it is done wrong, on big endian
> > systems all block indeces would be zero and they are part of the Derived
> > Key. I wonder if this has a security impact as in quality of derived key
> > on big endian systems.
> 
> You mean when int is big endian and 64bit? Do you see system where it is wrong
> or just guessing?
> 

Should happen on 32 Bit already, okay, let's see, AA BB CC DD, most
significant byte is AA (mask BB CC DD, shift right logically, so we will
get AA as value), which in little endian looks like AA 00 00 00, which
is copied into position Slen+0, the 4 bytes will be filled with AA 00 00
00, next step would be copying BB 00 00 00 into the next position Slen
+1, notice that here the last zero byte exceeds the buffer on the stack
already ...
After those 4 Ops we will have AA BB CC DD in the buffer and will have
written 4 zeros past the end of the buffer.
On big endian, the most significant byte AA is represented (after the
shift to the value AA) as 00 00 00 AA, we will copy this to slen+0, thus
filling it with 00 00 00 AA, next step fill 00 00 00 BB into slen+1 ...
and so on.
We will end up with all zeros for the index and will have written
various values in the 4 bytes past the buffer.

This is of course assuming an int is 4 bytes, if it is 64 bit, we will
corrupt the stack even more, as far as I can tell.

> There is no direct key encryption derived using this code, it is just keyslot
> obfuscation + keyslot passphrase verification (master key in LUKS is generated from RNG)
> (plain crypt do not use this at all)
> 
> That algorithm is not new and passed PBKDF2 test vectors (I will probably add this test
> to api check also).
> 
> I run test on several architectures - all keyslot operation should fail on prepared image
> if there is such bug.
> 
> (But it should explicitly use uint32 there.)
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt

Regards

-Sven


_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux