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

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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.

The scope of CVE-2013-7421 does not include any other parts of the
related 2013-03-03 discussion. In particular, the scope of
CVE-2013-7421 does not include the general concepts of "making things
safer with no real cost" and "Allowing simple, safe, well understood
work-arounds" in the https://lkml.org/lkml/2013/3/3/35 post. Also, the
scope of CVE-2013-7421 does not include any other security
implications, for other subsystems, of the "This isn't the case for
filesystems and a few others, unfortunately" observation in the
https://lkml.org/lkml/2013/3/3/88 post.


> 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.


> 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?


Finally, here is one more CVE ID for the last issue that PqFCo4bfrWu
mentions:

> https://bugs.busybox.net/show_bug.cgi?id=7652
> http://git.busybox.net/busybox/commit/?id=4e314faa0aecb66717418e9a47a4451aec59262b

Use CVE-2014-9645. The scope of this CVE ID is the entire problem of
path stripping. (In other words, CVE-2014-9645 is not specific to the
'If one would request a cipher named "/vfat"' attack, and is not
specific to the Crypto API.)

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJUw7GnAAoJEKllVAevmvmsSGYH+QGuxDsDlzYM7If+yc+qmSMh
RpG3iaenpzXCqDRePWl3d8ghKMP/ykkplzRxyAU9KFQYsC380u113eVcG/Jp7OL2
ARmzwqoYTJ9rIzicNOX2vEtZ2G3S1u57TPxjUEi/I1RD/L8b7LOeE1mb0/1MHvsP
eAIwPuBD6zS21wUpQow6Y9F3IlItJBkaMGXwqgxiO8ABD56rTKy+msBxDhxxvllR
noVwKZDsJteocQuhzS8Nb6M31T0mj8rszFpHyZLB54hTFyLY9u8nnjpJVpnjZi/R
ovw9Obe7+W2182KoNRNtXNwp9ztjjvh9QCc30vmB7ML07/raBVm1E/z/+ctMqo0=
=oBcQ
-----END PGP SIGNATURE-----