Date: Sat, 24 Jan 2015 09:53:42 -0500 (EST) From: cve-assign@...re.org To: marc.deslauriers@...onical.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request: Linux kernel crypto api unprivileged arbitrary module load -----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-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ