oss-security - RE: Handling CVEs for the XML entity expansion issues

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FC72FC641B949240B947AC6F1F83FBAF0697FE9E@IMCMBX01.MITRE.ORG>
Date: Wed, 20 Feb 2013 13:02:44 +0000
From: "Christey, Steven M." <coley@...re.org>
To: Kurt Seifried <kseifried@...hat.com>, "oss-security@...ts.openwall.com"
	<oss-security@...ts.openwall.com>
Subject: RE: Handling CVEs for the XML entity expansion issues

Kurt,

I'm reviewing this issue with the rest of the cve-assign team.  We will get back to you with an answer shortly.

- Steve


-----Original Message-----
From: Kurt Seifried [mailto:kseifried@...hat.com] 
Sent: Wednesday, February 20, 2013 3:22 AM
To: oss-security@...ts.openwall.com; Christey, Steven M.
Subject: Handling CVEs for the XML entity expansion issues

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

https://bitbucket.org/tiran/defusedxml
http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html

So two generic vulnerabilities have been found in XML libraries/parsers:

1) Unrestricted entity expansion induces DoS vulnerabilities in Python
XML libraries (XML bomb)
- - this can be referred to as the billion laughs / exponential entity
expansion, but can also be done linearly and still impact the system.
For example libxml fixed the billion laughs attack version of this,
but linear expansion (that eats up say a few hundred k of ram per
second) will still cause problems. This issue will not be CVE split
however since it's the same issue (expansion of entities).

For Python XML parsing this was assigned CVE-2013-1664


2) External entity expansion in Python XML libraries inflicts
potential security flaws and DoS vulnerabilities
- - XML documents can include references to external entities, e.g.
http:// resources:
<!ENTITY ee SYSTEM "http://www.example.org/some.xml">

For Python XML parsing this was assigned CVE-2013-1665

So questions:
======================

We need more CVE's, I think for each XML prasing library/etc we should
obviously assign a CVE (e.g. libxml, expat, internal Python parsers),
obviously fixing it at the root is ideal, but disabling external
entities for example in the library for all things using that library
is not possible.

But then we run into the issue where we can fix this issue within the
application (OpenStack, using Python):

+PARSER = etree.XMLParser(
+    resolve_entities=False,
+    remove_comments=True,
+    remove_pis=True)
+
+# NOTE(dolph): lxml.etree.Entity() is just a callable that currently
returns an
+# lxml.etree._Entity instance, which doesn't appear to be part of the
+# public API, so we discover the type dynamically to be safe
+ENTITY_TYPE = type(etree.Entity('x'))
+

- -        dom = etree.fromstring(xml_str.strip())
+        dom = etree.fromstring(xml_str.strip(), PARSER)

Which disables entity parsing in the application thus avoiding all the
entity expansion problems. Now I'm inclined in this case to say no CVE
(I had earlier, erroneously assigned CVE's for these fixes in
OpenStack). But now I'm not as sure, if an underlying library has an
unsafe/insecure behaviour that is on by default, BUT can be disabled
easily then does that vulnerability count as being in the library? If
not then I'd be inclined to say we need CVE's for all the vulnerable
applications, but in this case that's thousands (millions?) of
applications.

So Steve, I think we need some guidance on how to assign the CVEs here.
- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRJIebAAoJEBYNRVNeJnmTDN4QAIgwf74T2M6+4S6wj4h5EZP1
k/Cg0WW2AVPtN7nOsGg5Y5QdUCsGHtBoP9h/SWT21lch+DW3uYUhqgvtDpeyiGjc
XzDu8DNcmHnIFbq49RS5UTRpSdR35Y3oqd0lUi7yiRpiT4XpgfSHwI7BNR9L2Wm0
FUiwQDL9BULkD4wcq6NsagPiZCsaRmmezfUb/g5PxgYW84p56fYa5tg4SEQ7O4M/
lLNYDChfIis7gJVgqoLjbNClV36a2UWIGxIg/TCP8hVpmUpDMv04cxIbmtGWJ/tp
2iKzLNn25INaN80T6t0pzhC//R+jpWTkr9eFP4W7X+CA2Rs3sY0BA9Xvnyl9FPCF
gaQUTd7PyefKEM1Fm7OqFn1XbrtcKpOBThNI+NL5c/mrmud96DQwy8MMRaKDYhr1
W+fGxHBFD/Ztcffh/Dz1t/Ycm7T9BWzKQxitsubudZuEDQ7XfUilzLWQgy1X998J
T/Yjzsym8tkOoMvOe343caqDHTtBpq7eIFSXtJTTlXHIc5MiAT72406rak4/WVt0
qvrmhAxyOtWy8fOt2j/Qj9/rn8qYum9gBUFwHb4LWYRLADyK3lqThY3la/gMFYTi
y+KvwZf1FBtbXaJYZ3keO9ouMKNsvv9ll20Tke6wckFYPkLXRCs17quTHCx3Hh9J
MfZCwfOGm5G7O38k+vZ6
=V2n9
-----END PGP SIGNATURE-----
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.