Bug 1257962 (CVE-2015-7995) - CVE-2015-7995 libxslt: Type confusion may cause DoS
Summary: CVE-2015-7995 libxslt: Type confusion may cause DoS
Status: CLOSED WONTFIX
Alias: CVE-2015-7995
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20150826,repor...
Keywords: Security
: 1257058 (view as bug list)
Depends On: 1257983 1257058 1257982
Blocks: 1257974
TreeView+ depends on / blocked
 
Reported: 2015-08-28 13:56 UTC by Adam Mariš
Modified: 2016-09-26 21:05 UTC (History)
32 users (show)

(edit)
A type confusion vulnerability was discovered in the xsltStylePreCompute() function of libxslt. A remote attacker could possibly exploit this flaw to cause an application using libxslt to crash by tricking the application into processing a specially crafted XSLT document.
Clone Of:
(edit)
Last Closed: 2016-03-29 10:16:29 UTC


Attachments (Terms of Use)
Reproducer (140 bytes, application/xml)
2015-08-28 14:00 UTC, Adam Mariš
no flags Details
Simple fix for the bug (611 bytes, patch)
2015-10-26 11:37 UTC, Daniel Veillard
no flags Details | Diff

Description Adam Mariš 2015-08-28 13:56:13 UTC
A vulnerability in function xsltStylePreCompute" in preproc.c was found, the cause of which is a type confusion leading to DoS.

As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1257058 :

"""
Through analysis we get to know that parent->ns->href in line 2250 of preproc.c is an invalid value with our poc.
The whole process is as follow:
1> The main function in xsltproc.c will call xmlReadFile to read a .xml file. xmlReadFile will return a xmlDocPtr which points to the xmlDoc. When we print xmlDocPtr->children->parent->ns, its value is 0xffffffff. Obviously, this value is not a correct one.
2> Later in xsltStylePreCompute of preproc.c, the function will see whether current element is 'attribute', if yes,if inst->parent!=NULL and parent->ns!=NULL, then it will call xmlStrEqual, the first parameter is a ptr but its value is 0xffffffff!
3> We went further into libxml and see why this happened.The result is : in SAX2.c +2293 of libxml, we found that the first parameter "ctxt->myDoc" is a xmlDocPtr, but it will be teated as a xmlNodePtr. Obviously, xmlDoc and xmlNode have different structure. This is why "xmlDocPtr->children->parent->ns" get a invalid value(0xffffffff), this value comes from xmlDoc->compression.
"""

Comment 1 Adam Mariš 2015-08-28 14:00:19 UTC
Created attachment 1068010 [details]
Reproducer

How to reproduce:

./xsltproc poc

Comment 2 Adam Mariš 2015-08-28 14:25:06 UTC
Created libxslt tracking bugs for this issue:

Affects: fedora-all [bug 1257982]

Comment 3 Adam Mariš 2015-08-28 14:25:11 UTC
Created mingw-libxslt tracking bugs for this issue:

Affects: epel-7 [bug 1257983]

Comment 4 puzzor 2015-08-29 01:01:14 UTC
Why a new bug id created ? This is the same with my report : https://bugzilla.redhat.com/show_bug.cgi?id=1257058

Comment 5 Stefan Cornelius 2015-08-31 16:49:07 UTC
(In reply to puzzor from comment #4)
> Why a new bug id created ? This is the same with my report :
> https://bugzilla.redhat.com/show_bug.cgi?id=1257058

Hi puzzor, thank you for your report! We use various tools on top of Bugzilla, which require that bugs follow a strict format. Sometimes it's easier to create a completely new bug rather than modifying an existing one. Don't worry, not your fault.

Did you request a CVE ID for this issue yet? If you have not, that's perfectly fine - we'll handle all that for you (I'm just asking to avoid possible dupes).

Thanks!

Comment 6 puzzor 2015-09-01 01:01:26 UTC
Hi,

No, I didn't request for any CVE ID yet.

Thank you very much (In reply to Stefan Cornelius from comment #5)
> (In reply to puzzor from comment #4)
> > Why a new bug id created ? This is the same with my report :
> > https://bugzilla.redhat.com/show_bug.cgi?id=1257058
> 
> Hi puzzor, thank you for your report! We use various tools on top of
> Bugzilla, which require that bugs follow a strict format. Sometimes it's
> easier to create a completely new bug rather than modifying an existing one.
> Don't worry, not your fault.
> 
> Did you request a CVE ID for this issue yet? If you have not, that's
> perfectly fine - we'll handle all that for you (I'm just asking to avoid
> possible dupes).
> 
> Thanks!

Comment 8 Tomas Hoger 2015-09-21 11:27:32 UTC
*** Bug 1257058 has been marked as a duplicate of this bug. ***

Comment 9 puzzor 2015-10-11 01:31:07 UTC
Hello,

  Any status updated? Have you requested CVE?

Thanks

Comment 10 Fabio Olive Leite 2015-10-14 16:59:54 UTC
Switching the needinfo flag from the generic team address to Stefan.

Comment 11 Stefan Cornelius 2015-10-15 08:38:15 UTC
(In reply to puzzor from comment #9)
> Hello,
> 
>   Any status updated? Have you requested CVE?
> 
> Thanks

Hi, I've asked the maintainer to provide a patch on 2015-09-01 (visible only to RH). I've not requested a CVE yet.

Daniel, can you have a look and come up with a patch?

Comment 12 puzzor 2015-10-24 10:41:52 UTC
(In reply to Stefan Cornelius from comment #11)
> (In reply to puzzor from comment #9)
> > Hello,
> > 
> >   Any status updated? Have you requested CVE?
> > 
> > Thanks
> 
> Hi, I've asked the maintainer to provide a patch on 2015-09-01 (visible only
> to RH). I've not requested a CVE yet.
> 
> Daniel, can you have a look and come up with a patch?

Hi,it has been 70 days since I first reported this vul. Do you need extention and when will you request CVE ? What's next procedure?

Thanks

Comment 13 Daniel Veillard 2015-10-26 11:35:28 UTC
Dohhh I was only pointed at this now. Right it's a crasher, the nice point
is that there is a 1 liner patch.
I'm not sure I should commit it upstream if people want to go through a
CVE process and have an embargo, it's doable to guess the input based
on the fix for an libxml2 aware eye,

Daniel

Comment 14 Daniel Veillard 2015-10-26 11:37 UTC
Created attachment 1086465 [details]
Simple fix for the bug

Comment 15 Stefan Cornelius 2015-10-27 11:51:00 UTC
(In reply to Daniel Veillard from comment #13)
> Dohhh I was only pointed at this now. Right it's a crasher, the nice point
> is that there is a 1 liner patch.
> I'm not sure I should commit it upstream if people want to go through a
> CVE process and have an embargo, it's doable to guess the input based
> on the fix for an libxml2 aware eye,
> 
> Daniel

This is already public (including the reproducer). I'll open the proposed patch to the public, too - feel free to commit when you have time. I'll send a CVE request later tonight.

Comment 16 Stefan Cornelius 2015-10-27 12:49:41 UTC
CVE request:
http://www.openwall.com/lists/oss-security/2015/10/27/10

Comment 17 Daniel Veillard 2015-10-29 11:38:51 UTC
Pushed and tagged to upstream git

https://git.gnome.org/browse/libxslt/commit/?id=7ca19df892ca22d9314e95d59ce2abdeff46b617

this should apply without issue for any version in the last decade or so

Daniel

Comment 18 Stefan Cornelius 2015-12-15 14:24:38 UTC
Acknowledgements:

Red Hat would like to thank puzzor for reporting this issue.

Comment 20 puzzor 2015-12-16 03:06:00 UTC
(In reply to Stefan Cornelius from comment #18)
> Acknowledgements:
> 
> Red Hat would like to thank puzzor for reporting this issue.

Hello Stefan Cornelius,

Glad to hear that. But the credit info should be:

"Shi Ji(@Puzzor) and Weitao Hou of VARAS@IIE"

Thanks

Comment 21 Mike McCune 2016-03-28 23:33:48 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions


Note You need to log in before you can comment on or make changes to this bug.