[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201407191657.s6JGvmBm006264@linus.mitre.org>
Date: Sat, 19 Jul 2014 12:57:48 -0400 (EDT)
From: cve-assign@...re.org
To: kseifried@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Good news and bad news on Python sockets and pickle
-----BEGIN PGP SIGNED MESSAGE-----
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 (http://openwall.com/lists/oss-security/2012/09/05/16) 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
http://openwall.com/lists/oss-security/2014/07/08/13 post, where a CVE
ID was intentionally not assigned. Here,
https://bugs.launchpad.net/swift/+bug/1006414/comments/19 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 http://en.wikipedia.org/wiki/Red_Hat
article and calls pickle.loads on whatever it finds. Furthermore, the
documentation says that the http://en.wikipedia.org/wiki/Red_Hat
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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTyqK+AAoJEKllVAevmvmszakH/AjsOpWKubbJ1wqresPkYm2B
oFWKhyZs2IW72meH/Kevs/qMbyrZCh3JSl0UojXf9sZEr4Mp1zLEriUqMY5yTFM6
8oK20sg4FwArOxmJwgMqYmPL1VlrXbvH9FPoXrulrIQZ64EmDbDJ3TlWanWq6qhZ
18sSi2qHX+5AAhVy2j9VGxuOkPGHDEhzubjpWvJ3vLybp5IWSZJ4eLuzEysL7huJ
H01d+IseVykI1Pp+knsUk5uSrvKOILWzxoY10bnAb/zeznQC5uGN6GURFL+ef9IR
/qJFGo0bhth48pmMk1bmTmEf+kZOWOPh7uYRy9yXWq/dJQItzWAfTqOiKI8OdiQ=
=3NzC
-----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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
