Re: [xml] Runtime parser limit for maximum size of text nodes

On Mon, Jun 26, 2017 at 02:41:46PM +0200, Nick Wellnhofer wrote:
On 22/06/2017 22:29, Daniel Veillard wrote:
   No limit on text node and one can be DoS'ed, there is many kind
of recursive attacks on XML, and libxml2 uses a combination of "entities
density" and text node size to try to catch those, it's complex.
   By offloading the choice of the maximum text size to the application
developper you then put them in charge of doing the checking, i.e. too
big a size and the app can be DoS'ed in practice, it just depends on the
computer speed and memory anount. They need to be aware of that.

Right, this is something I overlooked. xmlParserEntityCheck should not use
the user-provided max text length. Otherwise, xmlSetMaxTextLength(ctxt,
SIZE_MAX) would disable one of the checks which wasn't my intention. We
should keep the hardcoded limit there.

The change of the size of the parsing context can bite some apps, that
happen in the past when I did this, maybe they have all been corrected,
but I would doubt it's gonna be 100% without side effects.

OK, I could revert this part of the change.

But thinking more about it, I come to the conclusion that libxml2 shouldn't
impose a limit on the maximum size of text nodes at all. If there's a
reliable mechanism to catch abusive entity expansions, the size of a text
node is bounded by the size of the input document. In fact, processing a
document containing a single 1 GB text node uses much less resources than a
document with 1 GB of "<e/>"s. The former should consume just a bit more
than 1 GB of memory for the text node, the latter will create 250 million
element nodes, consuming around 30 GB of memory on x86-64.

  I still think that one need to protect users with a default max
text node side. The problem is that libxml2 is very often used on untrusted
data, and if they can push a 30 GB document (not that hard on current networks)
then you're DoS'ed as well.
  Same for max depth of a document (1 GB of "<e>"), etc ...


