Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Feb 2013 11:47:50 -0700
From: Kurt Seifried <>
CC: Tim <>
Subject: Re: RE: Handling CVEs for the XML entity expansion

Hash: SHA1

On 02/20/2013 10:24 AM, Tim wrote:
> Hi Kurt and Steve,
> I have been investigating XXE issues and how they may be exploited
> off and on for the last year.  Most modern/maintained XML libraries
> enable parsing of inline DTDs (in DOCTYPE headers), as well as
> external entities defined there, by default.  Indeed, this is
> something that the XML standard includes
> ( and I'm guessing library
> implementors have a strong desire to comply.
> This is stupid, on two levels:
> - Most applications that actually apply DTD or schema validation
> will be working from a predefined definition.  Many applications
> don't bother to do any up-front validation.  In either case, what
> is the point in allowing a DTD (or schema) to be defined *within*
> the document that is being supplied?  From a security perspective,
> this is like say "Hey Mallory, I need to validate that search
> string input field.  Could you supply me with the regex so I can
> validate your data?"  I'm sure there are some odd contexts where
> XML developers find this feature useful, but I'm pretty sure they
> are few and far between. DTDs should be ignored by default by
> libraries unless supplied separately through the API.
> - External entities are a pretty dumb idea indeed.  I mean, I 
> understand why someone might want them.  Makes it easy to stitch 
> together multiple documents.  But in the vast majority of cases
> I've discussed XXE with developers, they have no idea that you can
> even define custom XML entities, let alone external ones.  These,
> too, should be off by default.

Docbook uses it quite a bit, e.g. each chapter is a file, then you use
external entities to put them all together, also for graphics/etc.
Breaking Docbook would make me a sad panda.

> Kurt, in regard to your question, my current opinion is that if an
> XML library doesn't make it easy/possible to disable these
> features, then yes they should be hit with a CVE.  But if they do
> make it possible, then it is the application developer's
> responsibility to turn these things off explicitly.  No, this isn't
> a good long-term solution, but it doesn't make sense to slap a CVE
> on a library that at least gives you the option.

I tend to agree, however for the billion laughs/linear attack that can
be somewhat addressed, libxml for example addressed it by stopping all
non linear expansion a few years ago, so while still vulnerable they
are less vulnerable.

> HTH, tim

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.13 (GNU/Linux)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ