dm-crypt accepts '+' in the key

dm-crypt accepts '+' in the key

[Mikulas Patocka]

Hi

dm-crypt uses the function kstrtou8 to decode the encryption key. kstrtou8 
calls kstrtoull and kstrtoull skips the first character if it is '+'.

Consequently, it is possible to load keys with '+' in it. For example, 
this is possible:

dmsetup create cr --table "0 131072 crypt aes-cbc-essiv:sha256 +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0 0 /dev/debian/tmptest 0"

Should this be fixed in dm-crypt or in kstrtou8? A fix in kstrtou8 could 
be more appropriate, but we don't know how many other kernel parts depend 
on this "skip plus" behavior...

Mikulas

Re: dm-crypt accepts '+' in the key

[Milan Broz]

On 11/12/2016 09:20 PM, Mikulas Patocka wrote:
> Hi
> 
> dm-crypt uses the function kstrtou8 to decode the encryption key. kstrtou8 
> calls kstrtoull and kstrtoull skips the first character if it is '+'.
> 
> Consequently, it is possible to load keys with '+' in it. For example, 
> this is possible:
> 
> dmsetup create cr --table "0 131072 crypt aes-cbc-essiv:sha256 +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0 0 /dev/debian/tmptest 0"
> 
> Should this be fixed in dm-crypt or in kstrtou8? A fix in kstrtou8 could 
> be more appropriate, but we don't know how many other kernel parts depend 
> on this "skip plus" behavior...

I would way it should be checked in both places...
For dmcrypt, it should validate input here and should
not accept anything in key field in dm table that is not in hexa representation.

(Is this regression since code switched from simple_strtoul to  kstrtou8
or this bug was there always?)

Milan

Re: dm-crypt accepts '+' in the key

[Alexey Dobriyan]

On Sun, Nov 13, 2016 at 03:45:27PM +0100, Milan Broz wrote:
> On 11/12/2016 09:20 PM, Mikulas Patocka wrote:
> > Hi
> > 
> > dm-crypt uses the function kstrtou8 to decode the encryption key. kstrtou8 
> > calls kstrtoull and kstrtoull skips the first character if it is '+'.
> > 
> > Consequently, it is possible to load keys with '+' in it. For example, 
> > this is possible:
> > 
> > dmsetup create cr --table "0 131072 crypt aes-cbc-essiv:sha256 +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0 0 /dev/debian/tmptest 0"
> > 
> > Should this be fixed in dm-crypt or in kstrtou8? A fix in kstrtou8 could 
> > be more appropriate, but we don't know how many other kernel parts depend 
> > on this "skip plus" behavior...
> 
> I would way it should be checked in both places...
> For dmcrypt, it should validate input here and should
> not accept anything in key field in dm table that is not in hexa representation.
> 
> (Is this regression since code switched from simple_strtoul to  kstrtou8
> or this bug was there always?)

Well, before kernel would silently parse anything broken as "0".

But since it is base-16, "0[xX]" will be accepted before every byte.

dm-crypt should parse key by hand, frankly.

Re: dm-crypt accepts '+' in the key

[Mikulas Patocka]

On Mon, 14 Nov 2016, Alexey Dobriyan wrote:

> On Sun, Nov 13, 2016 at 03:45:27PM +0100, Milan Broz wrote:
> > On 11/12/2016 09:20 PM, Mikulas Patocka wrote:
> > > Hi
> > > 
> > > dm-crypt uses the function kstrtou8 to decode the encryption key. kstrtou8 
> > > calls kstrtoull and kstrtoull skips the first character if it is '+'.
> > > 
> > > Consequently, it is possible to load keys with '+' in it. For example, 
> > > this is possible:
> > > 
> > > dmsetup create cr --table "0 131072 crypt aes-cbc-essiv:sha256 +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0 0 /dev/debian/tmptest 0"
> > > 
> > > Should this be fixed in dm-crypt or in kstrtou8? A fix in kstrtou8 could 
> > > be more appropriate, but we don't know how many other kernel parts depend 
> > > on this "skip plus" behavior...
> > 
> > I would way it should be checked in both places...
> > For dmcrypt, it should validate input here and should
> > not accept anything in key field in dm table that is not in hexa representation.
> > 
> > (Is this regression since code switched from simple_strtoul to  kstrtou8
> > or this bug was there always?)
> 
> Well, before kernel would silently parse anything broken as "0".

dm-crypt already validates that there are exactly two characters passed to 
kstrtou8 or simple_strtoul.

> But since it is base-16, "0[xX]" will be accepted before every byte.

Yes, the old dm-crypt code that used simple_strtoul accepted "0x" in a key 
(and parsed it as zero byte). It didn't accept "+" or "-".

> dm-crypt should parse key by hand, frankly.

Mikulas