paulk-asert opened a new pull request, #2858: URL: https://github.com/apache/groovy/pull/2858
Secure processing does not bound element depth. The JAXP limit that does, jdk.xml.maxElementDepth, defaults to 0 meaning unlimited, and nothing in groovy-xml set it, so the depth a document could reach was unbounded by default. The SAX parse itself survives that, because nesting is tracked on the heap rather than the stack. The damage lands on the first consumer to walk the result recursively - Node.text(), XmlNodePrinter, GPathResult.toString(), XmlUtil.serialize - each of which runs a stack frame per level. A 350KB document 50,000 elements deep parsed cleanly and then killed every one of them with a StackOverflowError. That is an Error, so it escapes the catch(Exception) an application would reasonably use to handle a malformed document: the failure arrives somewhere the caller is not defending, well after the parse it would have attributed it to. The limit is now set to 1000 by default, matching groovy.json's nesting bound, so a document too deep to walk is refused by the parse that reads it. The JDK enforces the bound itself, which puts the check ahead of every consumer at once and reports the offending element with its depth and position rather than unwinding an anonymous stack. The limit cannot be set on a SAXParserFactory - it is a parser property - so FactorySupport.createSaxParser applies it to the parser it creates, and the four places that built a SAX parser now go through it. The DocumentBuilderFactory route takes it as a factory attribute, which covers DOMBuilder and the DOM paths too. Nothing is applied when jdk.xml.maxElementDepth is already set: that is the standard knob for this limit, and an explicitly set parser property would otherwise override the value a user chose - including a deliberate 0 to restore unlimited depth. A parser supplied by the caller is left alone, as with the other hardening here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
