Bug 1257058

Summary: Libxslt 1.1.28 Type Confusion vulnerability may cause DOS
Product: [Other] Security Response Reporter: puzzor <puzzorsj>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Severity: low Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: scorneli, vkaigoro
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-09-21 11:27:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1257962    
Description Flags
corrupt xml file none

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 ***