See https://bugzilla.redhat.com/show_bug.cgi?id=852935: A heap-buffer overflow flaw was found in libxslt, a C library which allows to transform XML files into other XML files (or HTML, text, ...) using the standard XSLT stylesheet transformation mechanism. It was found that when applying templates to nodes selected by "namespace::*", a out-of-bounds read is performed. Later, this value is used during unlinking of nodes, leading to a WRITE error in xmlUnlinkNode(). Upstream patches to fix this issue: http://git.gnome.org/browse/libxslt/commit/?id=937ba2a3eb42d288f53c8adc211bd1122869f0bf http://git.gnome.org/browse/libxml2/commit/?id=6ca24a39d0eb7fd7378a5bc8be3286bf745a36ba
Oh, and also CVE-2012-2870 (https://bugzilla.redhat.com/show_bug.cgi?id=852937): Two Use-after-frees were found in libxslt, a C library which allows to transform XML files into other XML files (or HTML, text, ...) using the standard XSLT stylesheet transformation mechanism. One of them is caused due to an invalid XPath reference and the other is due to improper application of generate-id(). Patches: https://chromiumcodereview.appspot.com/10830177 https://chromiumcodereview.appspot.com/10823168
@security: Is fine to add CVE-2012-3972 here? http://www.mozilla.org/security/announce/2012/mfsa2012-65.html
(In reply to comment #2) > @security: > > Is fine to add CVE-2012-3972 here? > http://www.mozilla.org/security/announce/2012/mfsa2012-65.html Do we have confirmation that libxslt is affected by that CVE?
CVE-2012-2870 = libxslt CVE-2012-2871 = libxml2 Splitting these bugs up.
CVE-2012-2870 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-2870): libxslt 1.1.26 and earlier, as used in Google Chrome before 21.0.1180.89, does not properly manage memory, which might allow remote attackers to cause a denial of service (application crash) via a crafted XSLT expression that is not properly identified during XPath navigation, related to (1) the xsltCompileLocationPathPattern function in libxslt/pattern.c and (2) the xsltGenerateIdFunction function in libxslt/functions.c.
(In reply to comment #1) > Oh, and also CVE-2012-2870 > (https://bugzilla.redhat.com/show_bug.cgi?id=852937): > > Two Use-after-frees were found in libxslt, a C library which allows to > transform XML files into other XML files (or HTML, text, ...) using the > standard XSLT stylesheet transformation mechanism. One of them is caused due > to an invalid XPath reference and the other is due to improper application > of generate-id(). > > Patches: > > https://chromiumcodereview.appspot.com/10830177 > https://chromiumcodereview.appspot.com/10823168 I cannot figure out what conditions these patches are intended to address :( Could someone in @security who has access to http://code.google.com/p/chromium/issues/detail?id=138672, http://code.google.com/p/chromium/issues/detail?id=140368, and/or https://bugzilla.redhat.com/show_bug.cgi?id=852939 please check whether this upstream commit http://git.gnome.org/browse/libxslt/commit/?id=8566ab4a10158d195adb5f1f61afe1ee8bfebd12 is fixing the same problem as these two chromium commits?
(In reply to comment #6) > please check whether this > upstream commit > > http://git.gnome.org/browse/libxslt/commit/ > ?id=8566ab4a10158d195adb5f1f61afe1ee8bfebd12 > > is fixing the same problem as these two chromium commits? That commit is fixing what https://chromiumcodereview.appspot.com/10830177 is fixing (https://code.google.com/p/chromium/issues/detail?id=138672). You also need to take http://git.gnome.org/browse/libxslt/commit/?id=4da0f7e207f14a03daad4663865c285eb27f93e9 corresponding to https://chromiumcodereview.appspot.com/10823168 (https://code.google.com/p/chromium/issues/detail?id=140368). Here's the complete (to the best of my knowledge) list of libxslt security patches to backport: http://git.gnome.org/browse/libxslt/commit/?id=937ba2a3eb42d288f53c8adc211bd1122869f0bf http://git.gnome.org/browse/libxslt/commit/?id=8566ab4a10158d195adb5f1f61afe1ee8bfebd12 http://git.gnome.org/browse/libxslt/commit/?id=4da0f7e207f14a03daad4663865c285eb27f93e9
(In reply to comment #7) Thanks! Applied all the patches in libxslt-1.1.26-r4. >*libxslt-1.1.26-r4 (10 Sep 2012) > > 10 Sep 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > +files/0002-Hardening-ofcodecheckingnodetypesinvariousentrypoint.patch, > +libxslt-1.1.26-r4.ebuild, +files/libxslt-1.1.26-generate-id-crash.patch, > +files/libxslt-1.1.26-node-type-1.patch, > +files/libxslt-1.1.26-node-type-2.patch, > +files/libxslt-1.1.26-node-type-3.patch, > +files/libxslt-1.1.26-pattern-compile-crash.patch, > +files/libxslt-1.1.26-posix-comparison.patch: > Ensure special treatment for namespace nodes (CVE-2012-2871) and fix > use-after-free errors (CVE-2012-2870); bug #433603, thanks to Paweł Hajdan, > Jr. Fix non-posix comparison in configure; bug #420335, thanks to Richard > Yao.
(In reply to comment #8) > > Thanks! Applied all the patches in libxslt-1.1.26-r4. > Thank you. Ok to stabilize libxslt-1.1.26-r4?
(In reply to comment #9) > Ok to stabilize libxslt-1.1.26-r4? Yes.
Arches, please test and mark stable: =dev-libs/libxslt-1.1.26-r4 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Stable for HPPA.
amd64 stable
x86 done.
alpha/arm/ia64/m68k/s390/sh/sparc stable
Arches, please continue in bug #436284
This issue was resolved and addressed in GLSA 201401-07 at http://security.gentoo.org/glsa/glsa-201401-07.xml by GLSA coordinator Sergey Popov (pinkbyte).