Re: Re: CVE Request: Linux kernel crypto api unprivileged arbitrary module load

[Mathias Krause <minipli () googlemail com>]

On 24 January 2015 at 15:53,  <cve-assign () mitre org> wrote:
> > The Crypto API in the Linux kernel before 3.19 allowed unprivileged users to
> > load arbitrary kernel modules.
>
> > https://plus.google.com/+MathiasKrause/posts/PqFCo4bfrWu
>
> > https://lkml.org/lkml/2013/3/4/70
> > https://git.kernel.org/linus/5d26a105b5a73e5635eae0629b42fa0a90e07b7b
>
> Use CVE-2013-7421 for the original 2013 discovery by Mathias Krause,
> with a "Try the code snippet below on a system with
> CONFIG_CRYPTO_USER_API=y" attack.
> [...]

> > https://git.kernel.org/linus/4943ba16bbc2db05115707b3ff7b4874e9e3c560
>
> Use CVE-2014-9644 for this second discovery in 2014, mentioned in
> PqFCo4bfrWu as 'stumbled over the first flaw -- not handling crypto
> templates correctly. This means, the patch would prevent loading the
> vfat.ko module when requesting a cipher named "vfat" but would fail to
> do so if one would request "vfat(aes)" instead.' As far as we can
> tell, this is a discovery of a separate attack vector that wasn't
> implied by the 2013 post.

Even though this was a new discovery, not explicitly mentioned in the
initial report, it's the same bug, essentially -- using the AF_ALG
interface to load arbitrary modules. In fact, commits 5d26a105b5a7 and
4943ba16bbc2 should have been a single one in the first place. But for
whatever reasons commit 5d26a105b5a7 was applied, so the template
issue had to be fixed in the follow-up commit 4943ba16bbc2. However,
both commits were merged together into Linus' tree that ended up in
v3.19-rc1. See the merge commit at [1] and the discussion at [2] for
further reference.

[1] https://git.kernel.org/linus/e3aa91a7cb21
[2] http://www.mail-archive.com/linux-crypto () vger kernel org/msg12369.html

So I think CVE-2014-9644 should be marked as a duplicate of
CVE-2013-7421. It's the same issue, really.

> > https://git.kernel.org/linus/3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf
>
> This isn't within the scope of either CVE-2013-7421 or CVE-2014-9644.
> As far as we can tell, it is largely a usability fix. The example
> mentioned is "This fixes, e.g., requesting 'ecb(blowfish-generic)',
> which used to work with kernels v3.18 and below." Is there also a
> security impact if 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf is
> missing? For example, is it likely that code exists that requests
> ecb(blowfish-generic) in an environment without
> 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf, and is able to continue
> working afterward, but falls back to weak encryption?

It's just an API compliance fix to not regress the user interface for
the Crypt User API. No security fix, AFAICS.

Regards,
Mathias