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: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 5
  • Date: Tue, 12 Dec 2006 13:30:43 -0500

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. 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.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/




Archive powered by MHonArc 2.6.24.

Top of Page