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 <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Tim <tim-security@...tinelchicken.org>
Subject: Re: RE: Handling CVEs for the XML entity expansion
 issues

-----BEGIN PGP SIGNED MESSAGE-----
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
> (http://www.w3.org/TR/REC-xml/) 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRJRpWAAoJEBYNRVNeJnmT6CwQAJyxHDaddzK2peMokwAL+Yu5
VuAm5PAZ9NPe32NkD+W4kaCQZhMbfZxgV7l9w7P43igJ7cc9JRkCOZsYP8qqD1lH
0AGTI/9TTsCLxfgYqlT6Ypq9q0cgLMz6J5Z57IoQIW6/fPn7AdZIh61Xe44Fmmap
yHXwpnF/tBItSd8dCKUFN//q/VmaCy7QPp1aHt2pJP8IAJ/LPeIAS7kWyHKZ2FbH
fHbA9fCGoJdPgjoCf8h8CNLQDKpL+95IbVkZSRtauEfn2RGhEbPF6yqdFDq0bAR3
g5X+OXaGl3wkmmQiayS0TCS92768dlV8ZR6gPBUX39XqGUKUHJ94spDfgW6UIPRh
rjbnsmjVCWy+QosSLl29GSNGy09j4wTgtELIz3knMJF2FeXDaY45O0R2gRq/4jsK
Upvkh0Ct2vLkSd771iEZNg01pXL6NH7+oqEkNhfMIhCkm+K8hxz1OPbq7aIJIPnB
zvnsGF0uh8+28AyQywUHWYzab2sFbwPq+AgKz3vfvMGysRAM64+44dN85Mb6IJD/
B/qeVVnHL7a12QYBw52XS+9VmiMXUI/otITDQaWEc+xtFZR27FgnNYh/Yr8LOcfc
MNtlfINvYcB75re5iUUgr56453nuuyB4tQqGgqVlYxpDUHbY6UH0qYlBNqUAgeMH
FylXLZxER+fg8u/mN3FJ
=Bc6o
-----END PGP SIGNATURE-----

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