Bug 1257962 - (CVE-2015-7995) CVE-2015-7995 libxslt: Type confusion may cause DoS
CVE-2015-7995 libxslt: Type confusion may cause DoS
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20150826,repor...
: Security
: 1257058 (view as bug list)
Depends On: 1257983 1257058 1257982
Blocks: 1257974
  Show dependency treegraph
 
Reported: 2015-08-28 09:56 EDT by Adam Mariš
Modified: 2016-09-26 17:05 EDT (History)
32 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-29 06:16:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Adam Mariš 2015-08-28 09:56:13 EDT
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 10:00:19 EDT
Created attachment 1068010 [details]
Reproducer

How to reproduce:

./xsltproc poc
Comment 2 Adam Mariš 2015-08-28 10:25:06 EDT
Created libxslt tracking bugs for this issue:

Affects: fedora-all [bug 1257982]
Comment 3 Adam Mariš 2015-08-28 10:25:11 EDT
Created mingw-libxslt tracking bugs for this issue:

Affects: epel-7 [bug 1257983]
Comment 4 puzzor 2015-08-28 21:01:14 EDT
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 12:49:07 EDT
(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-08-31 21:01:26 EDT
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 07:27:32 EDT
*** Bug 1257058 has been marked as a duplicate of this bug. ***
Comment 9 puzzor 2015-10-10 21:31:07 EDT
Hello,

  Any status updated? Have you requested CVE?

Thanks
Comment 10 Fabio Olive Leite 2015-10-14 12:59:54 EDT
Switching the needinfo flag from the generic team address to Stefan.
Comment 11 Stefan Cornelius 2015-10-15 04:38:15 EDT
(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 06:41:52 EDT
(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 07:35:28 EDT
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 07:37 EDT
Created attachment 1086465 [details]
Simple fix for the bug
Comment 15 Stefan Cornelius 2015-10-27 07:51:00 EDT
(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 08:49:41 EDT
CVE request:
http://www.openwall.com/lists/oss-security/2015/10/27/10
Comment 17 Daniel Veillard 2015-10-29 07:38:51 EDT
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 09:24:38 EST
Acknowledgements:

Red Hat would like to thank puzzor for reporting this issue.
Comment 20 puzzor 2015-12-15 22:06:00 EST
(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 19:33:48 EDT
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.