[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51251A56.9080602@redhat.com>
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
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.
