Bug 1257962 (CVE-2015-7995)

Summary: CVE-2015-7995 libxslt: Type confusion may cause DoS
Product: [Other] Security Response Reporter: Adam Mariš <amaris>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: abaron, aortega, apevec, ayoung, bhu, carnil, chrisw, dallan, erik-fedora, esammons, gkotton, iboverma, jross, lhh, lpeer, markmc, matt, mcressma, mrg-program-list, osoukup, puzzorsj, rbryant, rhos-maint, rjones, sclewis, scorneli, security-response-team, sisharma, slong, tdecacqu, veillard, williams, yselkowi
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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 10:16:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1257058, 1257982, 1257983    
Bug Blocks: 1257974    
Attachments:
Description Flags
Reproducer
none
Simple fix for the bug none

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:04 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 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 with any questions