Crash due to uncaught DOMException
Description
Environment
Activity
Scott Cantor March 12, 2019 at 2:55 AM
Without going into detail, it turns out the conditions for the exception throw only occur under Xerces 3.2, so technically the issue isn't exploitable on older versions of the parser. But I wouldn't trust that very far and the fix was warranted.
Scott Cantor March 7, 2019 at 2:16 AM
Fix committed.
Scott Cantor March 7, 2019 at 1:25 AM
Review of exception classes is not encouraging and I don't think it's safe to assume the rest aren't problematic, so we should ship updates to the SP as part of this fix.
DOMException roots all of the DOM-based exceptions
SAXException is not an XMLException and I don't trust Xerces sufficiently to assume it couldn't raise one despite no use of SAX.
Other exceptions found that really should not be stand alone but are:
OutOfMemoryException
That's all I found, so not too long a list at least.
Scott Cantor March 7, 2019 at 1:15 AM
Confirmed parse method is documented as raising DOMException, so that was me.
Scott Cantor March 7, 2019 at 12:29 AM
The slightly different issue with this new bug is that it really should have been caught by the ParserPool itself, and I didn't realize that was leaking DOMExceptions. If the docs for DOMLSParser in the standard allow for DOM exceptions, that's definitely a bug even without knowing what Xerces did. If not, it's a bug but also a bug in Xerces outright I might someday be able to patch.
It would still be adviseable to trap DOMException elsewhere, but the actual bug is addressable with the xmltooling fix, and that may be relevant to downstream packagers so I'll move the issue there.
Another uncaught exception type in the listener code, DOMException this time. Triggerable with at least one trivial malformed XML example.
We need to fully review all the exception classes left in the Xerces codebase and hunt down any other missing cases, though I imagine this might be the only one.