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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ