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: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 5
  • Date: Tue, 12 Dec 2006 11:01:44 -0800


On Dec 12, 2006, at 10:30 AM, Elliotte Harold wrote:

Wolfgang Hoschek wrote:
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.

While I accept your point about different code paths for CDATA that might have different buffer overflows, I do not believe it is ever reasonable for a security department to attempt to black list particular code paths, absent a a demonstrated threat.

It's the equivalent of "all incoming ports closed by default", a successful strategy, it appears.

Taken to its logical conclusion, this would involve inspecting each if statement, and ruling in some paths through the application and ruling out others. This is simply ridiculous.

There are a few domains in which security is so important that only carefully vetted code is allowed in, and indeed every line of the code is checked. Possibly you even work in one such. However, there are very few of these environments. For instance, I don't think any installation that uses Microsoft Windows would qualify as such under an honest assessment.

In such an environment, you might choose to reject a particular library such as XOM or Xerces. You might even choose to reject XML completely if none of your fully-vetted applications could handle it. However you still wouldn't sensibly choose to allow XML without CDATA sections and forbid XML with CDATA sections unless you knew of a specific attack.

Ruling out particular code paths because *maybe* they have an unknown buffer overflow or other critical security flaw is too extreme. That standard would require us to eliminate all code paths. It is simply too hard and perhaps impossible to prove that *any* code path does not have such a flaw. *Every* code path fails to meet this standard.

Whitelisting is properly done at the library and application level, not at the code path level.


It's often unrealistic to carefully vet code, yes. Now, the overall complexity of a system tends to be a useful estimator for the number of flaws. Less complex systems tends to have a lower probability of flaws, at all levels of granularity, including app, library and code path level. Throwing away nonessential stuff tends to improve security. CDATA could be considered nonessential. John, yes, if necessary, one could appply that kind of reasoning also to attributes and namespaces et al...

Wolfgang.




Archive powered by MHonArc 2.6.24.

Top of Page