Follow @Openwall on Twitter for new release announcements and other news
[<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

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.