Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 19 Jul 2014 12:57:48 -0400 (EDT)
Subject: Re: Good news and bad news on Python sockets and pickle

Hash: SHA1

> here is my question, is all pickle.loads from things like memcached
> (which has no auth) generally CVE worthy?

The short answer is "not always" because sometimes there are
product-specific privilege boundaries.

> we do have this one in the past:
> CVE-2012-4406   OpenStack Object Storage (swift) before 1.7.0 uses the
> loads function in the pickle Python module unsafely when storing and
> loading metadata in memcached, which allows remote attackers to
> execute arbitrary code via a crafted pickle object.

The zeroth-order reason for why this exists is that you assigned a CVE
ID ( and we were
trying to cover all of those. This was not a CVE requested by the
OpenStack Vulnerability Management Team.

A relevant question is: what are the circumstances in which the data
obtained from memcached is considered 100% trusted data because
memcached is inside the privilege boundary of the machine making
pickle.loads calls, and all data had been validated before it was
stored by memcached. One case might be the "appliance" model. In other
words, the customer buys a box having those properties, the customer
has no ability to change the network architecture inside the box, and
thus pickle.loads is defined to be safe. In other words, either the
entire appliance is compromised, or it isn't.

Going up one level, there can be a situation where the documentation
says to deploy memcached on a trusted network, but a customer might
not accomplish this. This is the harder question of whether a CVE
inclusion decision can be affected by a product-specific privilege
boundary. It's essentially the same question that came up after the post, where a CVE
ID was intentionally not assigned. Here, might have
been interpreted in a similar way.

Finally, there may be cases in which the only reasonable conclusion is
that the data obtained from memcached is untrusted data. For example,
maybe a documented use case involves access to a memcached that is
intentionally, or at least practically, controlled by an arbitrary
third party. Maybe a cleaner example is: suppose a Red Hat product
looks for pickled data within the
article and calls pickle.loads on whatever it finds. Furthermore, the
documentation says that the
article is intentionally inside of the product's privilege boundary.
The outcome here is that a CVE ID can be assigned anyway because Red
Hat is simply not allowed to make that choice of a product-specific
privilege boundary. In general, maybe it depends on whether the
product-specific privilege boundary is one that customers could accept
as realistic.

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


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.