Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 5

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Adam Batkin <adam AT batkin.net>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 5
  • Date: Tue, 12 Dec 2006 09:42:02 -0800

Below is a response to Adam's comments but it equally applies to Mike's comments since they are overlapping:

On Dec 12, 2006, at 12:01 AM, Adam Batkin wrote:

Wolfgang Hoschek wrote:
On Dec 11, 2006, at 1:36 PM, Elliotte Harold wrote:

Jeff Williams wrote:

Gosh, I guess it's impossible to attack anything with XML in it. I'm
going to upgrade my rainbow- and puppy-based security system to
"happy
thoughts 2.0", now with XML.
It's certainly not possible to attack any real XML system by using
CDATA
unless you can carry out the same attack without using CDATA.

That's a claim with some adhoc reasoning behind it, but not anywhere
near a proof. Indeed, I'd be surprised if a credible proof emerged.
One day we could see the claim falsified by, say, a buffer overflow
exploit specific to CDATA in libxml or some other parser. Again, let
me repeat that this isn't about theory and "certainty" but about
practise:

An "all or nothing" (e.g. either you let XML in or not) security
model is inferior to a multi-layered
model (if layer 1 breaks, there's still layer 2 .. N left as
defense). It's another way of saying that practical security isn't
about making successful attacks impossible (you can't - get over it).
It's about making them as difficult as possible. Talk to folks who
run data centers.

Are you trying to imply that banning XML with CDATA sections inside can
be part of a good multi-layered security practice? I think the point
that some people were trying to make (and if they weren't, then I am) is
that anything that can be represented in a CDATA section can be also
represented in a non-CDATA section.

Sure, but that doesn't eliminate the code path inside a parser that's taken on detecting CDATA. There are distinct code paths for PCDATA and CDATA inside a parser, even though they ususally eventually merge up again. Further, even though PCDATA and CDATA are usually treated identical at a level above the parser (e.g. in the XOM object model), this is not always the case. Again, this implies distinct code paths that could be vulnerable in different ways.

If you ask me, that means that
banning CDATA sections is silly.*

Why? Why is it impossible to have a parser with a buffer overflow exploit that's triggered on receiving

<![CDATA[some stuff]]>

but isn't triggered on receiving the equivalent PCDATA

"some stuff"?

If we have a series of N doors to break through to reach the holy grail, each with an independent security mechanism of break-in probability 0 <= Px <= 1 then the overall probability P of breaking through all doors is

P = P1 * P2 * ... * Pn

With such a layered approach, the strength of security is a function of the length of the chain rather than it's weakest link. The probability of a CDATA exploit happening someday somewhere somehow is possibly small but it is non-zero (unless religion is involved), thus forbidding CDATA does reduce risk.

As noted before, designs balance factors such as security, accessability and cost depending on context. Protecting a shovel in a barn is different than protecting a biological weapons lab. For the shovel, a small reduction in theft risk may not justify the reduced accessibility to family members, and a heavy lock might costs more than the shovel anyway. One might even want to freely share the shovel with the community! For the weapons lab or data center or global financial institution the situation will likely be different even if probabilities are small. And even there it's problematic if tight security makes processes so complicated that hardly any real work can get done. Balance is called for. Whitelisting (conservatively preventing a feature such as CDATA unless it's explicitly known to be secure) may be excessive in one risk management situation and prudent in another. Your mileage may vary.


* The exception to this is if the security person in questions knows of
a specific attack vector involving CDATA sections (probably in a
specific parser, say, an overflow only when handling CDATA).
I highly
doubt this.

A conservative risk management approach doesn't forbid what's known to be insecure but instead allows what's known to be secure and forbids everything else.


That said, I think the whole argument about CDATA sections is a little
weird since (as others have pointed out) the security people may have
quite a bit of power to control things, and be living in a world of
superstition...so why argue.

It's all about balancing perspectives.


Just properly re-encode what would have
gone into a CDATA section and realize that what you get out at the end
is identical.

Cheers :-)

Wolfgang.






Archive powered by MHonArc 2.6.24.

Top of Page