From ${URL} : Description A vulnerability has been reported in libxml2, which can be exploited by malicious people to cause a DoS (Denial of Service) of an application using the library. The vulnerability is caused due to an error in the "xmlParserHandlePEReference()" function (parser.c) when expanding entity references and can be exploited to consume large amounts of memory and cause a crash or hang via a specially crafted XML file containing malicious attributes. Solution: Fixed in the source code repository. Further details available to Secunia VIM customers Provided and/or discovered by: Daniel Berrange, Red Hat. Original Advisory: llibxml2: https://git.gnome.org/browse/libxml2/commit/?id=9cd1c3cfbd32655d60572c0a413e017260c854df Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1090976 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Thanks for reporting. Fixed in =dev-libs/libxml2-2.9.1-r3; it should be stabilized, but a multilib version of icu needs to be stabilized first (bug #509856). +*libxml2-2.9.1-r3 (08 May 2014) + + 08 May 2014; Alexandre Rostovtsev <tetromino@gentoo.org> + +libxml2-2.9.1-r3.ebuild, +files/libxml2-2.9.1-external-param-entities.patch: + Fix denial of service vulnerability (CVE-2014-0191, bug #509834, thanks to + Agostino Sarubbo). Enable support for Python 3.4. Modernize python build as + suggested by Michał Górny
Arches, please test and stabilize =dev-libs/libxml2-2.9.1-r3 Target: all stable arches. Note that first you will need to stabilize icu-51.2-r2 (bug #509856).
Stable for HPPA.
arm stable
Please consider stopping the stabilization. The security patch applied to -r3 causes build problems for sys-auth/sssd[manpages]. Could you please review the patch and make sure it's correct? I opened bug #509834
Please consider stopping the stabilization. The security patch applied to -r3 causes build problems for sys-auth/sssd[manpages]. Could you please review the patch and make sure it's correct? I opened bug #509834(In reply to Markos Chandras from comment #5) > Please consider stopping the stabilization. > > The security patch applied to -r3 causes build problems for > sys-auth/sssd[manpages]. Could you please review the patch and make sure > it's correct? I opened bug #509834 I meant bug #510508
(In reply to Markos Chandras from comment #5) (In reply to Markos Chandras from comment #6) Thanks for reporting this; fixed in -r4. Arches, please test and stabilize =dev-libs/libxml2-2.9.1-r4 Target: all stable arches, including hppa and arm who already stabilized -r3, because -r3 will break builds and/or tests for packages that use xmllint for validating docbook etc. documents.
(In reply to Alexandre Rostovtsev from comment #7) > Thanks for reporting this; fixed in -r4. garblegarble -r4 > Arches, please test and stabilize =dev-libs/libxml2-2.9.1-r4 garblegarble garblegarble* =dev-libs/libxml2-2.9.1-r4 ? garblegarble garblegarble ! Please, next time, put each atom on a separate line. > Target: all stable arches, including hppa and arm who already stabilized > -r3, because -r3 will break builds and/or tests for packages that use > xmllint for validating docbook etc. documents. What targets? garblegarble garblegarble*hppa* garblegarble arm *garblegarble -- somethinggarblegarble! -r3 garblegarble because garblegarble. garblegarble! Oh, so that's: ---------------------------------------------------- Arch teams, here's the bait: =dev-libs/libxml2-2.9.1-r4 Targets: alpha amd64 arm arm64 hppa ia64 ppc ppc64 sparc x86 ---------------------------------------------------- See how that's actually recognisable and legible?
(In reply to Jeroen Roovers from comment #8) Is it too much to expect that the comment which adds an arch to the CC list would be read by a living human being subscribed to that arch's alias, and not just by a whitespace-sensitive regexp?
amd64 stable
x86 stable
alpha stable
(In reply to Alexandre Rostovtsev from comment #9) > (In reply to Jeroen Roovers from comment #8) > > Is it too much to expect that the comment which adds an arch to the CC list > would be read by a living human being subscribed to that arch's alias, and > not just by a whitespace-sensitive regexp? I don't use a script. I skim the comments looking to find something that looks like a human-readable instruction for architecture developers that includes a couple of vital bits of information. Because indeed, what comment "[added] an arch to the CC list"? When some of those bits are hard to find or missing, I skim more comments looking for clues. This can easily take minutes of my time as opposed to a few seconds. Now multiply that by the number of people who you wrote that information for in the first place. Do you mean you read news books, papers, websites and e-mails without text formatting and proper spacing exactly like you would read properly formatted text? Or do you mean that text formatting is too much work to expect one person to perform for a readership of a mere few dozen? Or do you mean that scripts should not take the work of honest humans? (Because making your text readable by scripts and humans alike sounds like an excellent plan, so yes, why don't we expect it, indeed?)
ia64 stable
ppc64 stable
ppc stable
sparc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Arches, Thank you for your work Maintainer(s), please drop the vulnerable version. New GLSA Request filed.
Vulnerable versions cleaned up. + 18 Jun 2014; Alexandre Rostovtsev <tetromino@gentoo.org> + -libxml2-2.9.1-r1.ebuild, -libxml2-2.9.1-r2.ebuild, -libxml2-2.9.1-r3.ebuild: + Punt old and vulnerable versions.
Maintainer(s), Thank you for cleanup!
This issue was resolved and addressed in GLSA 201409-08 at http://security.gentoo.org/glsa/glsa-201409-08.xml by GLSA coordinator Kristian Fiskerstrand (K_F).
CVE-2014-0191 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0191): The xmlParserHandlePEReference function in parser.c in libxml2 before 2.9.2, as used in Web Listener in Oracle HTTP Server in Oracle Fusion Middleware 11.1.1.7.0, 12.1.2.0, and 12.1.3.0 and other products, loads external parameter entities regardless of whether entity substitution or validation is enabled, which allows remote attackers to cause a denial of service (resource consumption) via a crafted XML document.
