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.