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.
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:
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:
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
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:
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:
In the new upstream issue:
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.
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.