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. """
Created attachment 1068010 [details] Reproducer How to reproduce: ./xsltproc poc
Created libxslt tracking bugs for this issue: Affects: fedora-all [bug 1257982]
Created mingw-libxslt tracking bugs for this issue: Affects: epel-7 [bug 1257983]
Why a new bug id created ? This is the same with my report : https://bugzilla.redhat.com/show_bug.cgi?id=1257058
(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!
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!
*** Bug 1257058 has been marked as a duplicate of this bug. ***
Hello, Any status updated? Have you requested CVE? Thanks
Switching the needinfo flag from the generic team address to Stefan.
(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?
(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
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
Created attachment 1086465 [details] Simple fix for the bug
(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.
CVE request: http://www.openwall.com/lists/oss-security/2015/10/27/10
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
(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
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions