Discussion:
CVE Request: additional fix for CVE-2012-2825 libxslt crash
(too old to reply)
Marcus Meissner
2013-11-05 12:50:09 UTC
Permalink
Hi,

Our QA found that the reproducer in CVE-2012-2825 (magic.xsl and magic.xml)
also expose another libxslt crash in older libxslt versions.

https://bugzilla.novell.com/show_bug.cgi?id=849019

This bug was fixed in libxslt 1.1.25 with this commit:
https://gitorious.org/libxslt/libxslt/commit/7089a62b8f133b42a2981cf1f920a8b3fe9a8caa

commit 7089a62b8f133b42a2981cf1f920a8b3fe9a8caa
Author: Martin <gzlist-gM/Ye1E23mwN+***@public.gmane.org>
Date: Wed Sep 16 19:02:16 2009 +0200

Crash compiling stylesheet with DTD

* libxslt/xslt.c: when a stylesheet embbeds a DTD the compilation
process could get seriously wrong

Crash as a xmlDtd struct is accessed as a xmlNode, not really attacker controllable
I would say, but a denial of service (crash).

Ciao, Marcus
Vincent Danen
2013-11-05 20:24:56 UTC
Permalink
Post by Marcus Meissner
Our QA found that the reproducer in CVE-2012-2825 (magic.xsl and magic.xml)
also expose another libxslt crash in older libxslt versions.
https://bugzilla.novell.com/show_bug.cgi?id=849019
https://gitorious.org/libxslt/libxslt/commit/7089a62b8f133b42a2981cf1f920a8b3fe9a8caa
commit 7089a62b8f133b42a2981cf1f920a8b3fe9a8caa
Date: Wed Sep 16 19:02:16 2009 +0200
Crash compiling stylesheet with DTD
* libxslt/xslt.c: when a stylesheet embbeds a DTD the compilation
process could get seriously wrong
Crash as a xmlDtd struct is accessed as a xmlNode, not really attacker controllable
I would say, but a denial of service (crash).
As you probably saw, I commented in your bug regarding this and now that
I've seen this I did some further digging.

The reason this doesn't crash for me on Red Hat Enterprise Linux 5 which
ships 1.1.17 is because we included this patch (well, the developer did)
a day after the initial build with the comment:

- CVE-2012-2825 requires an extra patch on 1.1.17

So, I think this does require a second CVE. This also explains why I
didn't see any crashes with our updated packages because we already have
this patch.
--
Vincent Danen / Red Hat Security Response Team
Florian Weimer
2013-11-05 22:17:21 UTC
Permalink
Post by Vincent Danen
The reason this doesn't crash for me on Red Hat Enterprise Linux 5 which
ships 1.1.17 is because we included this patch (well, the developer did)
- CVE-2012-2825 requires an extra patch on 1.1.17
So, I think this does require a second CVE.
Has anyone shipped an incomplete update? If yes, then I think we
actually need a second CVE. In the past, we got them for similar
cases, and at least Debian's tracking more or less assumes that it's
possible to assign CVEs to deal with such corner cases.
Marcus Meissner
2013-11-05 22:29:08 UTC
Permalink
Post by Florian Weimer
Post by Vincent Danen
The reason this doesn't crash for me on Red Hat Enterprise Linux 5 which
ships 1.1.17 is because we included this patch (well, the developer did)
- CVE-2012-2825 requires an extra patch on 1.1.17
So, I think this does require a second CVE.
Has anyone shipped an incomplete update? If yes, then I think we
actually need a second CVE. In the past, we got them for similar
cases, and at least Debian's tracking more or less assumes that it's
possible to assign CVEs to deal with such corner cases.
SUSE did, otherwise we would not have noticed :/

Ciao, Marcus
Vincent Danen
2013-11-05 23:50:33 UTC
Permalink
Post by Marcus Meissner
Post by Florian Weimer
Post by Vincent Danen
The reason this doesn't crash for me on Red Hat Enterprise Linux 5 which
ships 1.1.17 is because we included this patch (well, the developer did)
- CVE-2012-2825 requires an extra patch on 1.1.17
So, I think this does require a second CVE.
Has anyone shipped an incomplete update? If yes, then I think we
actually need a second CVE. In the past, we got them for similar
cases, and at least Debian's tracking more or less assumes that it's
possible to assign CVEs to deal with such corner cases.
SUSE did, otherwise we would not have noticed :/
Heh.

The other point is that CVE-2012-2825 affected before and after 1.1.25,
whereas this one really only affects < 1.1.25 so it's either a different
flaw or that commit (fixed in 1.1.25) is actually an incomplete fix, and
CVE-2012-2825 is the "fix of the fix" CVE.
--
Vincent Danen / Red Hat Security Response Team
Kurt Seifried
2013-11-06 01:08:31 UTC
Permalink
Post by Vincent Danen
Post by Marcus Meissner
Post by Florian Weimer
Post by Vincent Danen
The reason this doesn't crash for me on Red Hat Enterprise
Linux 5
which
Post by Vincent Danen
ships 1.1.17 is because we included this patch (well, the
developer
did)
Post by Vincent Danen
- CVE-2012-2825 requires an extra patch on 1.1.17
So, I think this does require a second CVE.
Has anyone shipped an incomplete update? If yes, then I think
we actually need a second CVE. In the past, we got them for
similar cases, and at least Debian's tracking more or less
assumes that it's possible to assign CVEs to deal with such
corner cases.
SUSE did, otherwise we would not have noticed :/
Heh.
The other point is that CVE-2012-2825 affected before and after
1.1.25, whereas this one really only affects < 1.1.25 so it's
either a different flaw or that commit (fixed in 1.1.25) is
actually an incomplete fix, and CVE-2012-2825 is the "fix of the
fix" CVE.
So to minimize confusion (I hope) because this became well known as a
security issue only recently I'm assigning a 2013 CVE instead of a
2009 CVE. Please use CVE-2013-4520 for this issue.

- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Loading...