[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130220210748.GQ2766@sentinelchicken.org>
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.
