Bug 1257058 - Libxslt 1.1.28 Type Confusion vulnerability may cause DOS
Summary: Libxslt 1.1.28 Type Confusion vulnerability may cause DOS
Status: CLOSED DUPLICATE of bug 1257962
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
Blocks: CVE-2015-7995
TreeView+ depends on / blocked
Reported: 2015-08-26 07:56 UTC by puzzor
Modified: 2015-09-21 11:27 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-09-21 11:27:32 UTC

Attachments (Terms of Use)
corrupt xml file (140 bytes, application/xml)
2015-08-26 07:56 UTC, puzzor
no flags Details

Description puzzor 2015-08-26 07:56:15 UTC
Created attachment 1067176 [details]
corrupt xml file

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:
./xsltproc poc

Actual results:
Denial of Service

Expected results:

Additional info:

Function "xsltStylePreCompute" in preproc.c may cause a denial of service, the root cause is a type confusion.
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.

Possible Patch:
Add a judgement in preproc.c+2248, before call xmlStrEqual we must determine whether parent->type equals XML_DOCUMENT_NODE

Comment 1 Tomas Hoger 2015-09-21 11:27:32 UTC

*** This bug has been marked as a duplicate of bug 1257962 ***

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