Date: Wed, 20 Feb 2013 13:07:48 -0800 From: Tim <tim-security@...tinelchicken.org> To: Kurt Seifried <kseifried@...hat.com> Cc: oss-security@...ts.openwall.com Subject: Re: RE: Handling CVEs for the XML entity expansion issues Hi Kurt, > Yeah I'm pretty sure that's a less than ideal solution. Less ideal in > the sense of "breaking a whole bunch of customer software without much > warning, some of which is probably closed source and can't be modified > so that it works with these new "improved" xml libraries" is not the > way to go. So that's not gonna happen for most major Linux vendors (in > other words we'll have to find better ways to fix this). > > Like Linus says, we can't just start breaking things. That's not how > you fix things. Yeah, Linus has a lot of opinions. Some of them are great. The fact of the matter is, any time you offer programmers an API where the most obvious way to do something is the insecure way (and doing it securely requires extra knowledge and effort), then you are virtually guaranteeing that a significant percentage of coders will screw up. Let me give you an example: Several years ago most web frameworks would allow you to set HTTP response headers that included new lines. These would not be escaped/encoded, so if you weren't careful, user supplied values could sneak malicious values into those headers allowing for HTTP header injection and response splitting. At the time, many apps that did an HTTP redirect using a dynamic URL or set the Content-Disposition header based on user file names would be vulnerable to header injection. This was bad. On the other hand, there may have been a handful of apps out there that needed this capability. Consider that a single HTTP header *can* have legal new lines in continuations, which may be necessary for longer headers. Within the span of just a year or so, most web frameworks began forbidding newlines in HTTP headers set by applications. Now the bugs are gone. Did it break backward compatibility? Yes. Who complained? When it comes to securing APIs, you really *do* need to look at the greater good and how the *public* is affected. Programmers aren't the ones who are really hurt by vulnerabilities, but when a single API design mistake is made, this is, multiplied N times for each application that ends up vulnerable, and again M times for each user using those apps. Trying to address this by educating programmers helps, but every year more programmers come out of school that need to be trained. Taking a closer look at the negative impact created by making API changes, let us do a breakdown of applications that use XML libraries and how they would be affected by a the change I propose: A. Applications that don't need inline DTDs and entities. B. Applications that do rely on inline DTDs or entities and are currently maintained. C. Applications that do rely on inline DTDs or entities and are not maintained. For (A), there is no problem. This is the *vast* majority of applications I see, and I test a lot of apps. For (B), the maintainers will need to make a one or two line change to their apps. Do they need to do this overnight? NO! I don't propose breaking things "without much warning". Any API change in a library must come in a major version change with good documentation on what it takes to upgrade. Transitions like this don't happen over night. But they do happen *all the time* in popular libraries. Dependency management to the rescue. For (C), these apps just continue relying on an old version of the library. Dependency management to the rescue. Also note that many XML developers consider DTDs and external entities to be *deprecated* in the first place. The sexy thing is to use schemas which don't allow entity definition, so most recent applications don't need to worry about any of this. You mentioned this is a less than ideal solution. Yeah, well when standards orgs make mistakes, there are never easy fixes. Recent SSL/TLS protocol flaws are a good recent example of that (we've had to disable SSL/TLS features, and ram through new RFCs). But that doesn't mean we should stick our head in the sand and hope programmers get the message over the next decade. The OWASP top 10 is still more than most developers can handle (SQLi and XSS are well over 10 years old). XXE can be more serious than most people understand and we need to nip it in the bud. Respectfully, tim
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.