For some reason, the mailing list seems to have eaten the text preceding my patches. They're there in the raw message, but they precede the mime headers. This text was actually present in my previous post that came out looking like only patches. Sorry about that.
To see the patches again, look at the previous message or check it out in the debian bugl <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=296432> --------------------- Executive Summary: I'm attaching my analysis of the changes for CAN-2004-1575 backported to 2.5.0 and 2.4.0 here. I'm also attaching my patches. My testing doesn't reveal any problems, but I'm honestly not sure that my testing is exercising this. I've run the automated test suites of the software I have that uses xerces, and I've also tested parsing a file with an element with < 20 and > 20 attributes and duplicate attributes. I can't say I was able to reproduce any major performance problems, but maybe 100 attributes isn't enough on my machine. I would be very grateful if someone could check this over and see if this is right. Once that's done, I'll be able to go ahead and put the fix into Debian, and perhaps add the information to the CVE candidate. Here are the details. Gareth Reakes <[EMAIL PROTECTED]> wrote: > Jay Berkenbilt wrote: > >> Can someone point me to an area of code that I should be looking at? >> A patch against an older version would be ideal but not necessary. If >> someone can just show me where in the code the problem was fixed in >> 2.6.0 as compared with 2.5.0, I can take it from there. Some files >> and CVS revisions or a date range would also help if I am to construct >> the patch myself. >> > > It would be in the scanners. They are in the internal directory and > end in Scanner (EG DGXMLScanner). For DGXMLScanner the revision number > the code was committed in was 1.54 with message > > "Optimized duplicated attributes checking for large number of attributes" > > Each of them will have the same message. I have to dash off now, but > if you have any problems I will happily help you make some patches. There were five files in that directory that had this message in their logs. I generated a patch using the following: cvs diff -u -r 1.39 -r 1.40 XMLScanner.hpp cvs diff -u -r 1.70 -r 1.71 XMLScanner.cpp cvs diff -u -r 1.24 -r 1.25 WFXMLScanner.cpp cvs diff -u -r 1.53 -r 1.54 DGXMLScanner.cpp cvs diff -u -r 1.71 -r 1.72 IGXMLScanner2.cpp and then read the patch to make sure I understood it. If I understood it correctly, XMLScanner.hpp and XMLScanner.cpp were modified to just add a function that sets the flag toUseHashTable if there are more than 20 attributes. The other three files modify the code for duplicate namespace attribute checking to use a hashtable if there are more than 20 attributes. The changes are pretty much the same in the three files: we set the flag, put the old code inside if (!toUseHashTable) and put the new code in the else. IGXMLScanner2 has the added logic that we only do this if fGrammarType == Grammar::DTDGrammarType and that we have one additional fAttrDupChkRegistry->put call outside the loop. Now, as far as I can tell, the code that had the problem was added to the scanners in this change: "Patch for bug #20530 - Attributes which have the same expanded name are not considered duplicates. Patch by cargilld." which occurred between 2.3.0 and 2.4.0. This means that versions prior to 2.4.0 will have the bug that this code fixed but will not be susceptible to the "attribute blowup" problem. This means only 2.4.0 and 2.5.0 are "vulnerable" to CAN-2004-1575. In attempting to apply the patch generated above to 2.5.0 and 2.4.0, the changes to XMLScanner.hpp and XMLScanner.cpp applied fine as did the changes to DGXMLScanner.cpp. In 2.5.0, there were problems with WFXMLScanner.cpp, and in 2.4.0 there were problems with both WFXMLScanner.cpp and IGXMLScanner2.cpp. In 2.5.0, for WFXMLScanner.cpp, all that was needed to get the patch to apply was to wrap the loop that checked for duplicates inside if (attCount) {...}. For 2.4.0, in WFXMLScanner.cpp, it was necessary to move the duplicate checking code outside of the loop that it was in and add an inner loop. This was the change from revision 1.19 to 1.20. Then wrapping that check inside the same if block was sufficient to get most of the patch to apply. The extra call to fAttrDupChkRegistry->put had to be inserted by hand because some of the code around it wasn't there, but it seemed fairly clear where to put it. In addition to attaching my 2.4 and 2.5 patches, I'm also attaching the patch I generated from CVS in case looking at this with the others makes the comparison easier. Please let me know if there's anything else I should do here. My goal is to make it as easy as possible for someone to review these changes so I can get the security fix upload into Debian right away. Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
