Your message dated Fri, 24 Oct 2008 20:33:36 -0400
with message-id <[EMAIL PROTECTED]>
and subject line CVE-2008-4882 not feasible to backport
has caused the Debian Bug report #502102,
regarding xerces-c2: CVE-2008-4482 denial of service via large maxOccurs value
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
502102: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502102
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Source: xerces-c2
Severity: grave
Tags: security
Hi,
the following CVE (Common Vulnerabilities & Exposures) id was
published for xerces-c2.
CVE-2008-4482[0]:
| The XML parser in Xerces-C++ before 3.0.0 allows context-dependent
| attackers to cause a denial of service (stack consumption and crash)
| via an XML schema definition with a large maxOccurs value, which
| triggers excessive memory consumption during validation of an XML
| file.
If you fix the vulnerability please also make sure to include the
CVE id in your changelog entry.
For further information see:
[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4482
http://security-tracker.debian.net/tracker/CVE-2008-4482
--
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
pgpjUj1c4zj0A.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
severity 502102 wishlist
tags 502102 +wontfix
thanks
After discussion with the security and release teams, I have decided
to downgrade this bug to wishlist, tag it wontfix, and close it. The
bug is not feasible to fix, and the security threat is relatively
minor. Here's my analysis for the record.
This CVE corresponds to two different upstream performance bugs. The
patches for these bugs can be found in these subversion revisions:
http://svn.apache.org/viewvc?view=rev&revision=676426
http://svn.apache.org/viewvc?view=rev&revision=676924
http://svn.apache.org/viewvc?view=rev&revision=677396
http://svn.apache.org/viewvc?view=rev&revision=677705
The changes here are substantial, and they were made on the trunk
during the pre-3.0.0 time period when the API/ABI was in flux. The
change is very large and not particularly localized. It introduces
API changes (and therefore also ABI changes), which is fine given
where it was fixed, but not acceptable for a security patch. The
patch affects 50 files, including 29 source or header files and a
Makefile.am, which implies that we would need to regenerate files in
the release as well.
We could ask upstream to backport the changes to the 2.x branch
without making any ABI changes, but that seems a bit much given the
complexity of the change and their desire to be spending their time
working toward 3.1.0, if it could be done at all. It's definitely
more than I care to try to take on, particularly given that upstream
took multiple tries to get it right in the first place.
Looking at the nature of the problem, I don't really think this is a
significant security risk. To really construct a denial of service
attack out of this, you'd have to manage to make someone parse a file
against a schema with a large minOccurs/maxOccurs value, and there are
a lot of easier ways of causing denial of service attacks than that.
I think that, rather than viewing this as a potential denial of
service attack, we should really view it as a case of a program
behaving in a correct fashion but handling certain large inputs very
inefficiently. The fix was to refactor code to make it able to handle
these inputs more efficiently. I don't see this as being
fundamentally different from something like trying to use ImageMagick
to work with an extremely large image file. It would happily use up
all the memory in your system, but it would be a stretch to call that
a denial of service attack. Other software, such as vips, is designed
to handle images much larger than RAM. If a user needs
minOccurs/maxOccurs values that are very large in an XML schema, we
should tell them to use xerces-c 3.0.0 or newer. Anyway, that's my
analysis, which I have shared with the security team.
For reference, I'm attaching the patch generated from the above
subversion revisions.
--Jay
xerces-c-CVE-2008-4882-patches.tar.gz
Description: Binary data
--- End Message ---
