[<prev] [next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.64.1304121857540.22586@faron.mitre.org>
Date: Fri, 12 Apr 2013 19:02:20 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: oss-security@...ts.openwall.com
Subject: Re-evaluating expat/libxml2 CVE assignments
Various CVEs were assigned to XML-related issues in expat and libxml2
at:
http://openwall.com/lists/oss-security/2013/02/22/3
CVE-2013-0338 - libxml2 internal entity expansion
CVE-2013-0339 - libxml2 external entities expansion
CVE-2013-0340 - expat internal entity expansion
CVE-2013-0341 - expat external entities expansion
As I noted in http://openwall.com/lists/oss-security/2013/02/21/24, for
novel situations such as these, sometimes we might change directions after
we learn more.
After some investigation, the MITRE CNA team believes we should probably
REJECT CVE-2013-0341 and shift responsibility to application developers.
For CVE-2013-0340 and CVE-2013-0339, there are "workarounds" available for
application developers, although such workarounds may be very expensive to
develop, and this might place "too much" responsibility to the developers
- so, these assignments may still be OK. It is still worth discussion.
CVE-2013-0338 still seems OK as is.
CVE-2013-0341 - expat external entities expansion
-------------------------------------------------
In http://openwall.com/lists/oss-security/2013/02/23/1, Kurt says "I
think it's common enough to warrant [assignment]," but Florian Weimer
points out that expat doesn't resolve external entities directly.
Instead - as described (or quoted?) in detail by Kurt - "Expat does
not read or parse external entities directly." The developer using
expat has to explicitly set ExternalEntityRefHandler, then create "a
subsidiary parser with XML_ExternalEntityParserCreate".
Since the programmer using expat has to do the work to define and set
up their ExternalEntityRefHandler, we believe that means that
individual applications are using expat unsafely, so there should be
separate CVEs for the applications, not expat.
CVE-2013-0340 - expat internal entity expansion
-----------------------------------------------
This probably qualifies for a CVE, but note that the issue came up in
CVE-2009-1955 (expat as used in Apache APR-util). The implemented
solution was to change the application, not expat. See
http://svn.apache.org/viewvc?view=rev&revision=781403
http://svn.apache.org/viewvc/apr/apr/trunk/xml/apr_xml.c?r1=757729&r2=781403&pathrev=781403&diff_format=h
Apparently, if an application wishes to address this issue, it has to
call the XML_SetEntityDeclHandler function with the name of an
alternative function that can handle entities more safely. The
opportunity to write your own code to process entities is probably
outside the general intention of our "the library provides an API
mechanism through which safe operation can be achieved" condition as
presented in the http://openwall.com/lists/oss-security/2013/02/21/24
post.
CVE-2013-0339 - libxml2 external entities expansion
---------------------------------------------------
This also probably qualifies for a CVE. This may be another situation
where the library provides the opportunity to write your own code to
process entities safely. The libxml2 documentation for
xmlSAX2ResolveEntity says "The entity loader, to control the loading
of external entities, the application can either: ... override this
xmlSAX2ResolveEntity() callback in the SAX block ... or better use the
xmlSetExternalEntityLoader() function to set up it's own entity
resolution routine." If so, then like CVE-2013-0340, it again would
arguably be outside the bounds of the "the library provides an API
mechanism through which safe operation can be achieved" condition.
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.
