Bug 1667950 (CVE-2019-6446) - CVE-2019-6446 numpy: crafted serialized object passed in numpy.load() in pickle python module allows arbitrary code execution
Summary: CVE-2019-6446 numpy: crafted serialized object passed in numpy.load() in pick...
Keywords:
Status: NEW
Alias: CVE-2019-6446
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20190116,repor...
Depends On: 1667958 1668465 1668466 1668467 1668469 1668829 1667955 1667956 1667957 1667959 1667960 1668468 1668507 1668508
Blocks: 1667968
TreeView+ depends on / blocked
 
Reported: 2019-01-21 15:00 UTC by msiddiqu
Modified: 2019-06-03 06:30 UTC (History)
28 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description msiddiqu 2019-01-21 15:00:20 UTC
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

Comment 1 msiddiqu 2019-01-21 15:05:47 UTC
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]

Comment 2 Jason Tibbitts 2019-01-22 15:57:15 UTC
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.

Comment 3 Scott Gayou 2019-01-22 19:37:44 UTC
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.

Comment 5 Joshua Padman 2019-01-22 22:53:41 UTC
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.

Comment 8 Tomas Hoger 2019-01-23 09:38:44 UTC
(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.

Comment 9 Tomas Hoger 2019-01-23 09:45:23 UTC
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.

Comment 12 Joshua Padman 2019-01-28 22:20:37 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.