XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

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.