Debian Bug report logs - #838097
XML::LibXML expands external entities by default

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "P. Benie" <pjb1008@cam.ac.uk>

To: submit@bugs.debian.org

Subject: XML::LibXML expands external entities by default

Date: Sat, 17 Sep 2016 11:55:08 +0100 (BST)

Package: libxml-libxml-perl
Version: 2.0116+dfsg-1+deb8u1

When I do an enternal entity attack against a program using
XML::LibXML, it works! This was unexpected as the underying
library, libxml2, has had its defaults changed to disable
external entity loading by default (as least when not validating).

The cause is that XML::LibXML has its own idea of 
what the defaults should be: XML_LIBXML_PARSE_DEFAULTS = ( 
XML_PARSE_NODICT | XML_PARSE_DTDLOAD | XML_PARSE_NOENT )
which causes it loads and expands the entities.

Example:

#!/usr/bin/perl -w
use XML::LibXML;

my $xml=<<END;
<!DOCTYPE root [ <!ENTITY ent SYSTEM "file:///etc/passwd"> ]>
<node>
    <e>&ent;</e>
</node>
END

print XML::LibXML->new()->parse_string($xml);

The issue is that XML-based application interfaces can be manipulated to 
cause programs to leak information.

I suggest that the default XML::LibXML parser options should be changed to 
match libxml2's defaults. This is where the libxml2 behaviour was changed:
https://git.gnome.org/browse/libxml2/commit/?id=4629ee02ac649c27f9c0cf98ba017c6b5526070f

Peter

Message #20 received at 838097@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: "P. Benie" <pjb1008@cam.ac.uk>, 838097@bugs.debian.org

Subject: Re: Bug#838097: XML::LibXML expands external entities by default

Date: Wed, 21 Sep 2016 16:26:56 +0200

Hi Bernie,

On Sat, Sep 17, 2016 at 11:55:08AM +0100, P. Benie wrote:
> Package: libxml-libxml-perl
> Version: 2.0116+dfsg-1+deb8u1
> 
> When I do an enternal entity attack against a program using
> XML::LibXML, it works! This was unexpected as the underying
> library, libxml2, has had its defaults changed to disable
> external entity loading by default (as least when not validating).
> 
> The cause is that XML::LibXML has its own idea of what the defaults should
> be: XML_LIBXML_PARSE_DEFAULTS = ( XML_PARSE_NODICT | XML_PARSE_DTDLOAD |
> XML_PARSE_NOENT )
> which causes it loads and expands the entities.
> 
> Example:
> 
> #!/usr/bin/perl -w
> use XML::LibXML;
> 
> my $xml=<<END;
> <!DOCTYPE root [ <!ENTITY ent SYSTEM "file:///etc/passwd"> ]>
> <node>
>     <e>&ent;</e>
> </node>
> END
> 
> print XML::LibXML->new()->parse_string($xml);
> 
> The issue is that XML-based application interfaces can be manipulated to
> cause programs to leak information.
> 
> I suggest that the default XML::LibXML parser options should be changed to
> match libxml2's defaults. This is where the libxml2 behaviour was changed:
> https://git.gnome.org/browse/libxml2/commit/?id=4629ee02ac649c27f9c0cf98ba017c6b5526070f

If the default should be changed, it is best to have that change upstream.
Currently the expand_entities behaviour is documented as
XML::LibXML::Parser(3pm):

       expand_entities
           /parser, reader/

           substitute entities; possible values are 0 and 1;
           default is 1

           Note that although this flag disables entity substitution, it
           does not prevent the parser from loading external entities;
           when substitution of an external entity is disabled, the
           entity will be represented in the document tree by an
           XML_ENTITY_REF_NODE node whose subtree will be the content
           obtained by parsing the external resource; Although this
           nesting is visible from the DOM it is transparent to XPath
           data model, so it is possible to match nodes in an unexpanded
           entity by the same XPath expression as if the entity were
           expanded. See also ext_ent_handler.

Could you please bring the question upstream?

Thanks a lot in advance, and for your report!

Regards,
Salvatore

Send a report that this bug log contains spam.