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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1611141607250.21467@file01.intranet.prod.int.rdu2.redhat.com>
Date:   Mon, 14 Nov 2016 16:09:53 -0500 (EST)
From:   Mikulas Patocka <mpatocka@...hat.com>
To:     Alexey Dobriyan <adobriyan@...il.com>
cc:     Milan Broz <gmazyland@...il.com>,
        Ondrej Kozina <okozina@...hat.com>,
        Mike Snitzer <msnitzer@...hat.com>, dm-devel@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: dm-crypt accepts '+' in the key



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ