An issue was discovered in NumPy 1.16.0 and earlier. It uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object, as demonstrated by a numpy.load call. Upstream issue: https://github.com/numpy/numpy/issues/12759 Upstream patch: https://github.com/numpy/numpy/commit/a2bd3a7eabfe053d6d16a2130fdcad9e5211f6bb
Created mingw-numpy tracking bugs for this issue: Affects: fedora-all [bug 1667956] Created numpy tracking bugs for this issue: Affects: fedora-all [bug 1667955] Created python2-numpy tracking bugs for this issue: Affects: epel-6 [bug 1667957] Affects: epel-7 [bug 1667959] Created python3-numpy tracking bugs for this issue: Affects: epel-6 [bug 1667958] Affects: epel-7 [bug 1667960]
The EPEL6 and EPEL7 python2-numpy packages are simply stub packages which contain no files and depend on python-numpy. They do not suffer from this or any other security issue.
Red Hat Enterprise Linux versions 6 and 7 call pickle.load and do not have the allow_pickle parameter. For Red Hat Software Collections, the same issue is present. python27-numpy - No allow_pickle parameter. rh-python35-numpy - allow_pickle, default is True, no docs on why that is unsafe. rh-python36-numpy - allow_pickle, default is True, no docs on why that is unsafe. The issue here is rather hard to rate. I am initially going to downgrade this from an Important to a Moderate as I don't think there is too much likelihood of this severely impacting anyone. For this to be exploitable, you'd really need some sort of custom web-service that implements a numpy.load API against untrusted data. Possible? Yes, certainly, but in my estimate, unlikely. I did a brief search, and did not find any packages we support that implement numpy.load in that manner. For information on why pickle is dangerous, see: https://docs.python.org/3/library/pickle.html To quote it: ``` Warning The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source. ``` Thus, using pickle on untrusted data can lead to code execution. I do agree that the fix should ideally set allow_pickle to false by default, and furthermore, should document that setting allow_pickle to true has security implications.
The Red Hat OpenStack version numpy supports the allow_pickle parameter but sets it to True as default and does not appear to document that there are potential security issues associated with pickle. There are no vulnerable uses of the load() function in Red Hat OpenStack.
(In reply to Scott Gayou from comment #3) > ... should document that setting allow_pickle to true has security implications. I think that is already covered by the numpy documentation: https://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.load.html#numpy.load """ numpy.load() allow_pickle : bool, optional Allow loading pickled object arrays stored in npy files. Reasons for disallowing pickles include security, as loading pickled data can execute arbitrary code. If pickles are disallowed, loading object arrays will fail. Default: True """ https://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.save.html#numpy.save """ numpy.save() allow_pickle : bool, optional Allow saving object arrays using Python pickles. Reasons for disallowing pickles include security (loading pickled data can execute arbitrary code) and portability (pickled objects may not be loadable on different Python installations, for example if the stored objects require libraries that are not available, and not all pickled data is compatible between Python 2 and Python 3). Default: True """ This is form the documentation for numpy 1.10.0, i.e. the version that introduced the allow_pickle parameter. This documentation change was made part of the commit that is linked in comment 0.
Note that the following upstream commit: https://github.com/numpy/numpy/commit/a2bd3a7eabfe053d6d16a2130fdcad9e5211f6bb that is noted in comment 0 as upstream patch does not completely address the problem. It add the allow_pickle parameter to numpy.load(), but its default is True. So any application calling numpy.load() on untrusted inputs remains vulnerable until it is modified to pass allow_pickle=False to the numpy.load(). This original fix was added in numpy 1.10.0. Also see the upstream pull request: https://github.com/numpy/numpy/pull/5770 In the new upstream issue: https://github.com/numpy/numpy/issues/12759 there's a discussion of changing the allow_pickle default to False, making numpy.load() safe by default. However, such change may break existing use cases that rely on the use of picle.
Statement: Red Hat Enterprise Virtualization Management Appliance includes the vulnerable version of numpy, however it is not used and this vulnerability is not exposed. Red Hat OpenStack Platform includes a vulnerable version of numpy, however it is not used in a vulnerable manner.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3335 https://access.redhat.com/errata/RHSA-2019:3335
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3704 https://access.redhat.com/errata/RHSA-2019:3704
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-6446